[Webkit-unassigned] [Bug 30989] [Gtk, WML] Assert failure in http://wap.google.com/wml

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30989





--- Comment #22 from Brady Eidson <beidson at apple.com>  2009-12-14 19:22:29 PST ---
(In reply to comment #21)
> (In reply to comment #20)
> > So there is no way to trigger this with non-WML content?  Changing
> > cross-platform frameloader code always makes me a little antsy.
> 
> No Eric, it is not possible to trigger this crash from non-WML contents. 

Okay.

> As mentioned in comment #2, redesign of History Handling/Page cache/loading in WML
> pages uncovered this bug in FrameLoader. Though I cannot test this fix in other
> platforms, I strongly feel issue should be reproducible in all platforms with
> WML enabled.

Okay.

So you can only reproduce this bug in WML builds but you're changing everyone's
build.  That's Eric's concern, which I share.

(In reply to comment #2)
> This assert wasn't seen in builds older revision 46418. There was a redesign of
> History handling / page cache / loading in WML pages, got fixed with bug
> #27707. This fix uncovered an existing issue in Frameloader which was causing
> this asset.

More correctly, the fix uncovered an existing issue in WML's assumptions about
FrameLoader.

> ...
> 
> This is because, FrameLoader::continueLoadAfterNavigationPolicy function used
> to set m_loadType to FrameLoadTypeReload after the call to stopAllLoaders().
> 
> ....
> ....
> FrameLoadType type = policyChecker()->loadType();
> stopAllLoaders();
> ...
> ...
> m_loadType = type;
> ...

In this context, stopAllLoaders() is a call attached to the *PREVIOUS* load. 
Which is why we don't set the new load type before it.

All sorts of interesting things happens from within stopAllLoaders() including
unload() and other events being dispatched and related WebKit API calls being
sent out to client applications.  Those client applications can then call back
in to WebKit where this flag being wrong is... wrong!.

> Meanwhile, stopAllLoaders() will in-turn call 'handleIntrinsicEventIfNeeded'.
> 'handleInstrinsicEventIfNeeded' will trigger the reload request based on load
> type, which is still FrameLoadTypeStandard. Ideally, we need to set m_loadType
> variable of FrameLoader class before calling stopAllLoaders().

If "handleIntrinsicEventIfNeeded" needs to know about the load type that is
ABOUT to occur as opposed to the load type that already occured, you need to
find a way to get that information there without changing this behavior for all
other ports.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.