#8055 closed defect (fixed)
Charting hangs browser when canvas is 0x0
Reported by: | Jared Jurkiewicz | Owned by: | Eugene Lazutkin |
---|---|---|---|
Priority: | high | Milestone: | 1.2.2 |
Component: | Charting | Version: | 1.2.1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
From a co-worker:
While trying to use charts within a floating pane widget I discovered that when the pane was "docked" and the chart's render() was called, the browser would lock up. After a little debug I figured out the problem was due to a canvas size of 0x0. This eventually leads to an infinite loop (divide by zero) in dojox.charting.scaler.linear at line 183:
while(while(next <= scaler.bounds.to + 1/scaler.bounds.scale){...}
Change History (7)
comment:1 Changed 12 years ago by
Priority: | high → normal |
---|---|
severity: | major → normal |
Status: | new → assigned |
comment:2 Changed 12 years ago by
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
I went to fixed the loop and ... it appears I fixed it already in the trunk. Please try with the trunk and reopen the ticket, if the problem still persist.
comment:3 Changed 12 years ago by
From my co-worker (A suggestion to make it behave saner, possibly):
Thanks. In the case of floating panes, I found the problem was being caused by a resize() call to the docked widget (with negative width and height!) but I could not determine what event this call was coming from. I am able to work around the problem by overriding the resize() function in the Chart2d widget with
resize: function(box){
if(box.w > 0 && box.h > 0){ this.inherited(arguments); }
}
Perhaps they could do something similar in the Chart2d widget as a simple fix for cases like this?
comment:4 Changed 12 years ago by
Milestone: | tbd → 1.2.2 |
---|---|
Resolution: | worksforme |
Status: | closed → reopened |
Yep, the resize fix sounds totally reasonable, thank you for the info. I'll push this change tonight.
And could you split off the widget for this "negative" resize for the Dijit team? Something is clearly wrong on their side of the resize business.
comment:5 Changed 12 years ago by
Will do. Ill try to get more info/testcase on where the negative resize occurs and get that to the dijit folks.
If you can tell me the files (or heck, send me the .patch), for the change you put into 1.2.2, that would be awesome as I can pull it in earlier here for my co-wroker. If not, I can just diff the branch and figure it out anyway, so no worries if you won't have time to gen an actual patchfile.
comment:6 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I'll push the change to the trunk and to 1.2.2 (thx Adam Peller for bringing it to my attention!).
Trac is acting up --- closing this ticket manually. Still it needs to be reported to the Dijit team.
"Invisible" charts are not supported --- all browsers have various problems with them on the gfx level. I'll fix the calculation when NaN was produced but it will not help the case, unless the chart will be completely redrawn when visible. But if the co-worker will put this logic in place, s/he can easily suppress generation of "invisible" chart as well.