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

[bugzilla-daemon at webkit.org]

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

--- Comment #18 from Andy Estes <aestes at apple.com> ---
(In reply to comment #17)
> Comment on attachment 275254 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=275254&action=review
> 
> Thanks Andy and Brent for giving comments!
> 
> >> 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:...

> 
> >> Tools/TestWebKitAPI/Tests/WebKit2Cocoa/LoadAlternateHTMLString.mm:48
> >> +}
> > 
> > Not sure you really need these functions.
> 
> I can't initiate a NSURL object easily by passing a string containing
> invalid URLs. However, with the help of WebCore::URLWithData, it can be done.

I get that part. I was just suggesting that you didn't need to create new functions to do this; just call URLWithData() directly.

-- 
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/f5708394/attachment.html>