Summary: | ASSERT in ~FrameView while viewing/reloading WICD test case | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> | ||||||
Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | mitz, timur.mehrvarz | ||||||
Priority: | P1 | Keywords: | NeedsReduction | ||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
URL: | http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/test-SVG-DOM-events.xhtml | ||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 15836, 16491, 16626 | ||||||||
Attachments: |
|
Description
Eric Seidel (no email)
2007-12-17 15:12:18 PST
This reproduces for me every time after a couple reloads. Created attachment 18117 [details]
Balance pauseScheduledEvents() with resumeScheduledEvents()
In this case the timer is activated by an inner layout(), so the outer layout has paused but will not resume.
Created attachment 18131 [details]
Balance pauseScheduledEvents() with resumeScheduledEvents()
Simplified and add a layout test that fails even in unpatched release builds.
Comment on attachment 18131 [details]
Balance pauseScheduledEvents() with resumeScheduledEvents()
This fixes the bug. I don't like this sort of order-sensitive design however (completely not your fault). In the future, I would love to see this code move to some sort of stack object which would do the pausing for us since all (except maybe the one which pauses before the timer and resumes after) could use a stack object instead of manual calls.
Something like:
ScheduledEventsPauser(frameView);
(awful name, I know)
|