RESOLVED FIXED 209587
Move applyUserAgentIfNeeded calls to a more central place
https://bugs.webkit.org/show_bug.cgi?id=209587
Summary Move applyUserAgentIfNeeded calls to a more central place
Rob Buis
Reported 2020-03-26 01:53:27 PDT
Move applyUserAgentIfNeeded calls to a more central place.
Attachments
Patch (8.58 KB, patch)
2020-03-26 01:55 PDT, Rob Buis
no flags
Patch (9.30 KB, patch)
2020-03-26 03:33 PDT, Rob Buis
no flags
Patch (8.17 KB, patch)
2020-03-26 04:13 PDT, Rob Buis
no flags
Patch (8.57 KB, patch)
2020-04-22 12:05 PDT, Rob Buis
no flags
Rob Buis
Comment 1 2020-03-26 01:55:15 PDT
Rob Buis
Comment 2 2020-03-26 03:33:06 PDT
Rob Buis
Comment 3 2020-03-26 04:13:49 PDT
EWS
Comment 4 2020-03-27 09:12:41 PDT
Committed r259116: <https://trac.webkit.org/changeset/259116> All reviewed patches have been landed. Closing bug and clearing flags on attachment 394594 [details].
Radar WebKit Bug Importer
Comment 5 2020-03-27 09:13:13 PDT
Chris Dumez
Comment 6 2020-04-22 08:37:35 PDT
Reverted r259116 for reason: Broke login flow on some apple-internal sites (rdar://problem/61905262) Committed r260511: <https://trac.webkit.org/changeset/260511>
Darin Adler
Comment 7 2020-04-22 08:40:54 PDT
We know that this revision caused the login failures. We don’t know what behavior changed. Need to figure that out, make tests, to make sure future refactoring doesn’t break this again.
Chris Dumez
Comment 8 2020-04-22 08:43:16 PDT
(In reply to Darin Adler from comment #7) > We know that this revision caused the login failures. We don’t know what > behavior changed. Need to figure that out, make tests, to make sure future > refactoring doesn’t break this again. Understood. I will follow-up with more investigation and hopefully a test. For now, my priority is to get us back into a working state.
Chris Dumez
Comment 9 2020-04-22 08:58:05 PDT
(In reply to Chris Dumez from comment #8) > (In reply to Darin Adler from comment #7) > > We know that this revision caused the login failures. We don’t know what > > behavior changed. Need to figure that out, make tests, to make sure future > > refactoring doesn’t break this again. > > Understood. I will follow-up with more investigation and hopefully a test. > For now, my priority is to get us back into a working state. I did some digging with Web Inspector and it looks like if you do a navigation like so: "window.location = 'test.html';" then WebCore no longer sets the User-Agent header on the main resource request to test.html
Chris Dumez
Comment 10 2020-04-22 09:03:35 PDT
Comment on attachment 394594 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=394594&action=review > Source/WebCore/loader/FrameLoader.cpp:-2979 > - applyUserAgentIfNeeded(request); For the scenario I mentioned, this used to add the user-agent header.
Chris Dumez
Comment 11 2020-04-22 10:05:59 PDT
(In reply to Chris Dumez from comment #10) > Comment on attachment 394594 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=394594&action=review > > > Source/WebCore/loader/FrameLoader.cpp:-2979 > > - applyUserAgentIfNeeded(request); > > For the scenario I mentioned, this used to add the user-agent header. I was wrong, the User-Agent header seems to be missing from sync XHR requests. I have a test almost ready.
Rob Buis
Comment 12 2020-04-22 10:11:11 PDT
(In reply to Chris Dumez from comment #11) > (In reply to Chris Dumez from comment #10) > > Comment on attachment 394594 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=394594&action=review > > > > > Source/WebCore/loader/FrameLoader.cpp:-2979 > > > - applyUserAgentIfNeeded(request); > > > > For the scenario I mentioned, this used to add the user-agent header. > > I was wrong, the User-Agent header seems to be missing from sync XHR > requests. I have a test almost ready. Thanks for your work here! My patch probably did not add an applyUserAgentIfNeeded to FrameLoader::loadResourceSynchronously, to correct the applyUserAgentIfNeeded that was removed from addExtraFieldsToRequest.
Chris Dumez
Comment 13 2020-04-22 10:25:23 PDT
(In reply to Darin Adler from comment #7) > We know that this revision caused the login failures. We don’t know what > behavior changed. Need to figure that out, make tests, to make sure future > refactoring doesn’t break this again. Added test that would have failed via https://bugs.webkit.org/show_bug.cgi?id=210863.
Rob Buis
Comment 14 2020-04-22 12:05:07 PDT
Darin Adler
Comment 15 2020-04-22 14:22:57 PDT
Comment on attachment 397229 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=397229&action=review > Source/WebCore/loader/cache/CachedResourceLoader.h:178 > - void updateHTTPRequestHeaders(CachedResource::Type, CachedResourceRequest&); > + void updateHTTPRequestHeaders(FrameLoader&, CachedResource::Type, CachedResourceRequest&); This doesn’t seem good.
Rob Buis
Comment 16 2020-04-22 21:39:03 PDT
Comment on attachment 397229 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=397229&action=review >> Source/WebCore/loader/cache/CachedResourceLoader.h:178 >> + void updateHTTPRequestHeaders(FrameLoader&, CachedResource::Type, CachedResourceRequest&); > > This doesn’t seem good. Can you expand on what is not good? This is the original patch plus the fix to loadResourceSynchronously.
Darin Adler
Comment 17 2020-04-23 09:15:56 PDT
Comment on attachment 397229 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=397229&action=review >>> Source/WebCore/loader/cache/CachedResourceLoader.h:178 >>> + void updateHTTPRequestHeaders(FrameLoader&, CachedResource::Type, CachedResourceRequest&); >> >> This doesn’t seem good. > > Can you expand on what is not good? This is the original patch plus the fix to loadResourceSynchronously. Having to pass a FrameLoader here bothers me. But it’s not really about this one patch.
Rob Buis
Comment 18 2020-04-23 13:33:43 PDT
Comment on attachment 397229 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=397229&action=review >>>> Source/WebCore/loader/cache/CachedResourceLoader.h:178 >>>> + void updateHTTPRequestHeaders(FrameLoader&, CachedResource::Type, CachedResourceRequest&); >>> >>> This doesn’t seem good. >> >> Can you expand on what is not good? This is the original patch plus the fix to loadResourceSynchronously. > > Having to pass a FrameLoader here bothers me. But it’s not really about this one patch. I see, one impovement may be to inline this more in CachedResourceLoader::requestResource, and make sure to order well and add the right comments and spec links. There is probably still quite some we can do to improve that method, I made a start here https://bugs.webkit.org/show_bug.cgi?id=210925.
EWS
Comment 19 2020-04-23 13:37:58 PDT
Committed r260596: <https://trac.webkit.org/changeset/260596> All reviewed patches have been landed. Closing bug and clearing flags on attachment 397229 [details].
Alex Christensen
Comment 20 2020-06-25 16:37:47 PDT
Note You need to log in before you can comment on or make changes to this bug.