[webkit-reviews] review requested: [Bug 28683] Timers from cached pages fire instantly rather than the specified timeout delay : [Attachment 38584] Updated patch.
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Aug 25 17:56:54 PDT 2009
Dmitry Titov <dimich at chromium.org> has asked for review:
Bug 28683: Timers from cached pages fire instantly rather than the specified
timeout delay
https://bugs.webkit.org/show_bug.cgi?id=28683
Attachment 38584: Updated patch.
https://bugs.webkit.org/attachment.cgi?id=38584&action=review
------- Additional Comments from Dmitry Titov <dimich at chromium.org>
(In reply to comment #3)
> (From update of attachment 38572 [details])
> +PASS with 206 ms delay.
> Will cause this to fail on some systems.
Replaced with just 'PASS', output real delay only if failed - in case reduced
timeout will cause problems it'd be nice to know what it was in a test run.
(In reply to comment #5)
> (From update of attachment 38572 [details])
> +#ifndef NDEBUG
> + , m_suspended(false)
> +#endif
>
> Seems like you should guard this with #if !ASSERT_DISABLED instead of the
> NDEBUG check, just in case some crazy person comes along and turns on
> assertions on a Release build, or turns them off on a Debug build.
Done.
(In reply to comment #6)
> Does the delay during the test need to be as large as 200 ms? Ideally we'd
> like our regression tests to be much quicker than that.
Replaced with 100 ms. I measured time needed on my Mac Pro, debug build, in
DRT, to navigate to another page and back - it was a bit under 50ms. I figured
double this to be sure it fails in most cases. If it doesn't fail on a slow
machine it's probably ok since it will fail on retail build for sure.
(In reply to comment #7)
> (From update of attachment 38572 [details])
> r=me with minor tweaks - prepare for some extreme nit-pickyness ;)
> > + Timers from cached pages fire instantly rather than the specified
timeout delay
> "...rather than after the specified timeout delay," maybe.
Done.
> > + remove duplicated Frame::restore() call, it should be done only
once in FraeLoader::open(cachedFrame)
> Typo "FrameLoader"
Done.
> You capitalized all statements in the LayoutTest ChangeLog - should
capitalize
> all the WebCore/ChangeLog stuff, too.
Done.
(In reply to comment #9)
> Although there's clearly a bug in code, it's not clear to me what the right
> behavior is. If we start a 1 second timer and suspend the page for 5 seconds,
> I'd personally expect it to fire immediately after resuming. As Ada said,
> testing other browsers is the key.
Tested FF3.5, it behaves as this patch. Attached the test page for reference.
More information about the webkit-reviews
mailing list