[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 #17 from Jiewen Tan <jiewen_tan at apple.com> ---
Comment on attachment 275254
  --> https://bugs.webkit.org/attachment.cgi?id=275254
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.

>> 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.

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