Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#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:


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 <= + 1/scaler.bounds.scale){...}

Change History (7)

comment:1 Changed 14 years ago by Eugene Lazutkin

Priority: highnormal
severity: majornormal
Status: newassigned

"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.

comment:2 Changed 14 years ago by Eugene Lazutkin

Resolution: worksforme
Status: assignedclosed

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 14 years ago by Jared Jurkiewicz

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 14 years ago by Eugene Lazutkin

Milestone: tbd1.2.2
Resolution: worksforme
Status: closedreopened

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 14 years ago by Jared Jurkiewicz

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 14 years ago by Eugene Lazutkin

Resolution: fixed
Status: reopenedclosed

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.

comment:7 Changed 14 years ago by Eugene Lazutkin

Sorry: the change was pushed to both repositories.

Note: See TracTickets for help on using tickets.