Bug 211007

Summary: Prepare to remove automatic URL->String conversion operators
Product: WebKit Reporter: Alex Christensen <achristensen>
Component: New BugsAssignee: Alex Christensen <achristensen>
Status: RESOLVED FIXED    
Severity: Normal CC: aboxhall, alecflett, apinheiro, beidson, benjamin, calvaris, cdumez, cfleizach, cmarcelo, darin, dino, dmazzoni, eric.carlson, esprehn+autocc, ews-watchlist, fmalita, glenn, gyuyoung.kim, hi, japhet, jcraig, jdiggs, jer.noble, joepeck, jsbell, kangil.han, keith_miller, Lawrence.j, macpherson, mark.lam, menard, mifenton, mkwst, msaboff, pdr, philipj, saam, sabouhallawa, samuel_white, schenney, sergio, toyoshim, tzagallo, webkit-bug-importer, yutak
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch
ews-feeder: commit-queue-
patch with export macro none

Description Alex Christensen 2020-04-24 18:43:29 PDT
Prepare to remove automatic URL->String conversion operators
Comment 1 Alex Christensen 2020-04-24 18:46:42 PDT
Created attachment 397534 [details]
Patch
Comment 2 Alex Christensen 2020-04-24 19:59:08 PDT
Created attachment 397537 [details]
Patch
Comment 3 Darin Adler 2020-04-25 10:22:16 PDT
Comment on attachment 397537 [details]
Patch

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

> Source/WTF/wtf/URL.cpp:317
> +    return WTF::protocolIsJavaScript(string());

I think a better implementation of this would be:

    return protocolIs("javascript");

> Source/WebCore/bindings/IDLTypes.h:35
>  #include <wtf/text/WTFString.h>

Can remove this since we are including URL.h now.

> Source/WebCore/inspector/agents/InspectorPageAgent.cpp:533
> -            if (!document->page()->cookieJar().getRawCookies(*document, URL({ }, url), rawCookiesForURLInDocument))
> +            if (!document->page()->cookieJar().getRawCookies(*document, url, rawCookiesForURLInDocument))

Wow, nice to fix this! Now I am happier with the change after seeing this.

> Source/WebCore/loader/DocumentLoader.cpp:1514
> -        if (auto subresource = this->subresource({ { }, handle->url() }))
> +        if (auto subresource = this->subresource(handle->url()))

Another!

> Source/WebCore/loader/TextTrackLoader.cpp:151
> -    ResourceRequest resourceRequest(m_document.completeURL(url));
> +    ResourceRequest resourceRequest(m_document.completeURL(url.string()));

This seems really peculiar and is worth revisiting to see if it’s correct. I agree that the patch does not change behavior, but this seems wrong.

> Source/WebCore/workers/WorkerScriptLoader.cpp:64
> -            m_responseURL = URL { URL { }, scriptResource->responseURL };
> +            m_responseURL = scriptResource->responseURL;

Another of these "throw away URL and recreate it" cases.

> Source/WebKit/WebProcess/WebPage/WebFrame.cpp:187
> -        ResourceRequest(URL(URL(), url())),
> +        ResourceRequest(url()),

And ... *another*!

> Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:630
> -    URL mainFrameURL = { URL(), mainFrame.url() };
> +    URL mainFrameURL = mainFrame.url();

And ... *another*. OK, totally sold.
Comment 4 Alex Christensen 2020-04-25 13:07:37 PDT
(In reply to Darin Adler from comment #3)
> Comment on attachment 397537 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=397537&action=review
> 
> > Source/WTF/wtf/URL.cpp:317
> > +    return WTF::protocolIsJavaScript(string());
> 
> I think a better implementation of this would be:
> 
>     return protocolIs("javascript");
That's what I thought too, but that failed some tests.  WTF::protocolIsJavaScript is needed to return true for invalid URLs that are valid JS URLs.

> > Source/WebCore/bindings/IDLTypes.h:35
> >  #include <wtf/text/WTFString.h>
> 
> Can remove this since we are including URL.h now.
Yes.

> > Source/WebCore/loader/TextTrackLoader.cpp:151
> > -    ResourceRequest resourceRequest(m_document.completeURL(url));
> > +    ResourceRequest resourceRequest(m_document.completeURL(url.string()));
> 
> This seems really peculiar and is worth revisiting to see if it’s correct. I
> agree that the patch does not change behavior, but this seems wrong.
I agree.  I added a FIXME comment.
Comment 5 Alex Christensen 2020-04-25 13:11:07 PDT
Created attachment 397577 [details]
Patch
Comment 6 Alex Christensen 2020-04-25 13:45:41 PDT
Created attachment 397579 [details]
patch with export macro
Comment 7 EWS 2020-04-25 13:53:41 PDT
Patch 397577 does not build
Comment 8 EWS 2020-04-25 14:28:50 PDT
Committed r260709: <https://trac.webkit.org/changeset/260709>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 397579 [details].
Comment 9 Radar WebKit Bug Importer 2020-04-25 14:29:24 PDT
<rdar://problem/62376149>
Comment 10 Darin Adler 2020-04-25 16:57:57 PDT
(In reply to Alex Christensen from comment #4)
> That's what I thought too, but that failed some tests. 
> WTF::protocolIsJavaScript is needed to return true for invalid URLs that are
> valid JS URLs.

Sounds dangerously subtle. We may need to consider how to redefine how these calls work for invalid URLs to protect people in the future.
Comment 11 Darin Adler 2020-04-25 17:41:10 PDT
(In reply to Darin Adler from comment #10)
> (In reply to Alex Christensen from comment #4)
> > That's what I thought too, but that failed some tests. 
> > WTF::protocolIsJavaScript is needed to return true for invalid URLs that are
> > valid JS URLs.
> 
> Sounds dangerously subtle. We may need to consider how to redefine how these
> calls work for invalid URLs to protect people in the future.

I think we might want to change URL parsing so that JavaScript URLs are always "valid" but don’t have any parts other than the protocol. I’d like to hear your thoughts on this.
Comment 12 Alex Christensen 2020-04-27 10:45:33 PDT
https://trac.webkit.org/changeset/260765/webkit

Changing JavaScript URL parsing would likely cause incompatibilities
Comment 13 Darin Adler 2020-04-27 10:52:21 PDT
(In reply to Alex Christensen from comment #12)
> Changing JavaScript URL parsing would likely cause incompatibilities

I’m proposing changes to JavaScript URL validity rules, not to other aspects of parsing. Are you *sure* that would cause incompatibilities? Can we at least try it?

Our URL::protocolIs("javascript") and URL::protocolIsJavaScript are dangerous as long as we have many URLs that will execute JavaScript, but return false to those. At least we should remove them!
Comment 14 Alexey Proskuryakov 2020-04-28 18:02:01 PDT
*** Bug 211086 has been marked as a duplicate of this bug. ***