#261 closed defect (worksforme)
IE crashes when adding dojo.debug to SplitPane.js onResized handler
| Reported by: | M4g3 | Owned by: | anonymous |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | Widgets | Version: | 0.2 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: |
Description
When I try and add a dojo.debug message to the onResized handler in SplitPane?.js the cpu usage jumps to 100% and the window becomes unresponsive.
Adding it to another handler or somewhere else in my page works fine. FireFox? 1.5 works fine as well.
I attached my version of SplitPane?.js (added "dojo.debug('a');" after line 77) and the page I used to test (copied from the unit tests)
Attachments (2)
Change History (6)
Changed 13 years ago by
Changed 13 years ago by
| Attachment: | SplitPane.js added |
|---|
comment:1 Changed 13 years ago by
| Milestone: | → 0.3release |
|---|
comment:2 Changed 13 years ago by
comment:3 Changed 13 years ago by
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
Actually my statement above refers to when you the debug statements increase the length of the page (when the page is longer than the viewport). I tried your testcase and couldn't reproduce. Does it happen w/the newest code? Does it happen when you are acessing dojo via file:// rather than http://? That's what I tried and it worked for me.
Note: See
TracTickets for help on using
tickets.
Yeah, I've seen this. Printing to the screen causes a resize event, which effectively causes onResized() to be called in an endless loop. Hopefully we can be more intelligent about detecting whether things have _really_ been resized or not.