Bug 41178 - Timed refresh in subframes isn't stopped when going into b/f cache
Summary: Timed refresh in subframes isn't stopped when going into b/f cache
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Frames (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P1 Normal
Assignee: Alexey Proskuryakov
URL:
Keywords: InRadar
: 41028 41120 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-06-24 14:40 PDT by Alexey Proskuryakov
Modified: 2010-06-24 17:15 PDT (History)
4 users (show)

See Also:


Attachments
proposed fix (6.89 KB, patch)
2010-06-24 16:18 PDT, Alexey Proskuryakov
beidson: review+
beidson: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 2010-06-24 14:40:58 PDT
Loading inside a cached frame causes all sorts of crashes. Patch forthcoming.
Comment 1 Alexey Proskuryakov 2010-06-24 16:18:25 PDT
Created attachment 59706 [details]
proposed fix

Let's dupe other bugs that are likely caused by this problem to this one.
Comment 2 Alexey Proskuryakov 2010-06-24 16:18:47 PDT
<rdar://problem/8128955>
Comment 3 Brady Eidson 2010-06-24 16:27:01 PDT
Comment on attachment 59706 [details]
proposed fix


>  
> Index: WebCore/loader/FrameLoader.cpp
> ===================================================================
> --- WebCore/loader/FrameLoader.cpp	(revision 61698)
> +++ WebCore/loader/FrameLoader.cpp	(working copy)
> @@ -491,10 +491,7 @@ void FrameLoader::stopLoading(UnloadEven
>  #endif
>      }
>  
> -    // tell all subframes to stop as well
> -    for (Frame* child = m_frame->tree()->firstChild(); child; child = child->tree()->nextSibling())
> -        child->loader()->stopLoading(unloadEventPolicy);
> -
> +    // FIXME: This will cancel redirection timer, which really needs to be restarted when restoring the frame from b/f cache.
>      m_frame->redirectScheduler()->cancel();

Don't we restore redirect timers for the main frame when restoring from the page cache?

If so, is it acceptable to have this outstanding FIXME for subframes?


>  
> Index: LayoutTests/ChangeLog
> ===================================================================
> --- LayoutTests/ChangeLog	(revision 61786)
> +++ LayoutTests/ChangeLog	(working copy)
> @@ -1,3 +1,16 @@
> +2010-06-24  Alexey Proskuryakov  <ap@apple.com>
> +
> +        Reviewed by NOBODY (OOPS!).
> +
> +        https://bugs.webkit.org/show_bug.cgi?id=41178
> +        Timed refresh in subframes isn't stopped when going into b/f cache
> +
> +        This is a slow test, because a fast redirect results in replacing the current item in b/f
> +        list, so back/forward cache doesn't get involved. But this code path must be tested.
> +

Even if it's an inconvience to everyone while folks are still working at parallelizing and otherwise speeding up the layouttests, I agree we absolutely need this type of test, even if it's slow.

> +        * fast/history/timed-refresh-in-cached-frame-expected.txt: Added.
> +        * fast/history/timed-refresh-in-cached-frame.html: Added.

Maybe we should to create a new TLD in LayoutTests 'slow' for this type of test?

r- because of my question on the FIXME
Comment 4 Geoffrey Garen 2010-06-24 16:50:38 PDT
Looks good to me, modulo Brady's comments.
Comment 5 Alexey Proskuryakov 2010-06-24 16:53:17 PDT
Comment on attachment 59706 [details]
proposed fix

> Don't we restore redirect timers for the main frame when restoring from the page cache?

We don't. Pages that come back from page cache are almost dead, see semi-related bug 34679.

> Maybe we should to create a new TLD in LayoutTests 'slow' for this type of test?

I don't think it would be helpful. The reason to have multiple directories is that one can run only a subset of tests pertinent to the code area while iteratively developing a patch (e.g., I've been running fast/history, fast/events and fast/frames for this patch).

And this test isn't the slowest that we have!
Comment 6 Brady Eidson 2010-06-24 16:54:28 PDT
Comment on attachment 59706 [details]
proposed fix

Okay, you got me.
Comment 7 Alexey Proskuryakov 2010-06-24 16:59:09 PDT
Committed <http://trac.webkit.org/changeset/61801>.
Comment 8 Alexey Proskuryakov 2010-06-24 17:05:10 PDT
*** Bug 41028 has been marked as a duplicate of this bug. ***
Comment 9 Alexey Proskuryakov 2010-06-24 17:05:59 PDT
*** Bug 41120 has been marked as a duplicate of this bug. ***
Comment 10 Darin Adler 2010-06-24 17:15:43 PDT
Comment on attachment 59706 [details]
proposed fix

Looks good.