[Webkit-unassigned] [Bug 136916] Pending API request URL no set when loading Alternate HTML or plain text

[bugzilla-daemon at webkit.org]

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

--- Comment #14 from Carlos Garcia Campos <cgarcia at igalia.com> ---
Comment on attachment 243974
  --> https://bugs.webkit.org/attachment.cgi?id=243974
Now also including the xcode file changes

View in context: https://bugs.webkit.org/attachment.cgi?id=243974&action=review

>>> Source/WebKit2/UIProcess/WebPageProxy.cpp:860
>>> +    m_pageLoadState.setPendingAPIRequestURL(transaction, ASCIILiteral("about:blank"));
>> 
>> I think it’s a little peculiar to actually set the URL to about::blank here. Do we agree that explicitly giving it this particular URL makes sense? Does WebKit already treat this as if it came from that URL in other ways or is that a new concept we are introducing? If WebKit does already use this URL then why are we having to inject it specifically here?
>> 
>> I think this would read better without the local variable even though the other function does have it in a local variable since it uses it twice. I think blankURL().string() is better than ASCIILiteral("about:blank").
>> 
>>     m_pageLoadState.setPendingAPIRequestURL(m_pageLoadState.transaction(), blankURL().string());
> 
> I found comments in FrameLoader::reload that say, "If a window is created by javascript, its main frame can have an empty but non-nil URL."
> 
> Maybe that’s how the plain text string should work. Have an empty URL, not "about:blank".

This is what we are doing in other load methods, see WebPageProxy::loadHTMLString() and WebPageProxy::loadData(). You can see in the unit test I'm adding that it also checks existing cases like WKPageLoadData that indeed returns about:blank. So, I don't know if it's the best to do it, but it's consistent with what we do already.

-- 
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/20160202/57a297ce/attachment.html>