[Webkit-unassigned] [Bug 155995] WebKit should dispatchDidFailProvisionalLoad while loading invalid URLs

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 31 19:01:46 PDT 2016


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

--- Comment #20 from Andy Estes <aestes at apple.com> ---
(In reply to comment #19)
> Comment on attachment 275254 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=275254&action=review
> 
> >>>> Source/WebKit2/UIProcess/WebPageProxy.cpp:1008
> >>>> +    if (m_isClosed || m_isDealingFailingProvisionalLoad)
> >>> 
> >>> Wouldn't any new load started in response to a provisional load failure cause this problem? For instance, if the client called loadRequest: instead of _loadAlternateHTMLString:baseURL:forUnreachableURL:, would you see the same assertion? If so, seems like we need a fix that won't involve adding checks like this to every loading entry point in the UI process. I'm ok with this for now, since you are handling what Safari does, but we might need to come up with a better long-term solution.
> >> 
> >> I don't think other APIs have the same problem. It should be only specific to loadAlternateHTMLString as the way we tell if we are in the process of responding to a provisional load failure in WebProcess is to check whether FrameLoader ::m_provisionalLoadErrorBeingHandledURL is empty. This member is only set/clear at WebPage::loadAlternateHTMLString.
> > 
> > No, that's not true. m_provisionalLoadErrorBeingHandledURL is set in FrameLoader whenever there's a provisional load failure. It's also set in WebPage::loadAlternateHTMLString(), but that's just to account for the fact that WebKit2 clients do not load alternate HTML synchronously.
> > 
> > My question was whether the assertion failure you saw would also occur in the presence of two sequential provisionally failing loads when the client responded to the second one with something other than _loadAlternateHTMLString:...
> 
> I think the situation you mentioned is fine, but what will cause problems is
> replacing the first one with some other load APIs.
> 
> Once WebProcess enter the state of loadAlternateHTMLString, it will lose the
> ability to send DidFailProvisionalLoad error through
> checkLoadCompleteForThisFrame to the clients, and therefore any back to back
> load before loadAlternateHTMLString will cause the assertion to hit.
> 
> The way how loadAlternateHTMLString lock things down is too heavy. I don't
> have any idea to fix this for long term so far.

It isn't urgent since we don't know if any clients actually do this, but filing a bug and writing some test cases is a good place to start. Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160401/d13b951f/attachment.html>


More information about the webkit-unassigned mailing list