[wpt-sync] Sync PR 34879 - Fix document.referrer on about:blank creation
Categories
(Core :: DOM: Core & HTML, task, P4)
Tracking
()
Tracking | Status | |
---|---|---|
firefox104 | --- | fixed |
People
(Reporter: mozilla.org, Unassigned)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [wptsync downstream])
Sync web-platform-tests PR 34879 into mozilla-central (this bug is closed when the sync is complete).
PR: https://github.com/web-platform-tests/wpt/pull/34879
Details from upstream follow.
Dominic Farolino <dom@chromium.org> wrote:
Fix document.referrer on about:blank creation
The HTML Standard assigns
document.referrer
[1] in two ways:
1.) During Document/browsing context creation
2.) Upon navigation to a new DocumentFor creation (1):
Per the HTML Standard's "create a new browsing context" algorithm [2] step 3, all new browsing contexts with a non-null creator (always same-BCG) have their "creator URL" set to the creator document's full URL, unredacted and subjected to no referrer policy sanitization. Later in step 20, we set the referrer of the newly-created document to the newly-created browsing context's creator URL.For navigation (2):
In "create and initialize a Document object", with the referrer from
"navigation params" [3]
In Blink, we handle
document.referrer
assignment the same for both creation and navigation; we simply setDocumentLoader::referrer_
to what the resultingWebNavigationParams
carries [4], and we don't do anything special for the browsing context creation case. This leads to the finaldocument.referrer
on Documents being created in new BCs actually being incorrectly subjected to referrer policy sanitization/redaction.Due to existing issues, Chrome does not perfectly follow the HTML Standard for creation of new browsing contexts. In short, for iframes we create a new browsing context/document [5] and immediately navigate it to about:blank [6]. This navigation commits synchronously via a special
path that tries to make up for Blink's mismatch with the spec [7].During this synchronous about:blank navigation, the request's referrer is computed as "" (in FrameLoadRequest::ctor), because the origin of the "about:blank" URL is opaque and therefore cross-origin with the embedder, and the default referrer policy is
strict-origin-when-cross-origin
.For newly created windows (with openers, since this is only relevant for windows with "creators"), something very similar happens. We create a FrameLoadRequest whose referrer gets set to "" (in FrameLoadRequest::ctor as well as [8]), and we perform the special-case synchronous navigation which ends up with the resulting document having an empty referrer, just like in the iframe case.
This CL fixes the above issues by modifying
RenderFrameImpl::SynchronouslyCommitAboutBlankForBug778318()
to find the initiator frame (should be equivalent to the spec's "creator" Document), if it is local (should be the case for about:blank subframes and new windows w/o "noopener"), and sets the navigation params's referrer member to the initiator Document's full unredacted URL. This will be used to set the eventualDocumentLoader::referrer_
member when the synchronous navigation commits, which will be used to reflect the correct value todocument.referrer
.In cases where we don't go through Blink's special sync navigation case,
document.referrer
is unchanged.
[1]: https://html.spec.whatwg.org/multipage/dom.html#dom-document-referrer and https://html.spec.whatwg.org/multipage/dom.html#the-document's-referrer
[2]: https://html.spec.whatwg.org/multipage/browsers.html#creating-a-new-browsing-context
[3]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigating-across-documents:the-document's-referrer-2
[4]: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/loader/document_loader.cc;l=322;drc=5dffcc4991ab32edc7dbc99c3b4685882c029ab0
[5]: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/html_frame_owner_element.cc;l=827-828;drc=6fd9edfbb85bc5fb2ed8f9300abe83cd03ab54b7
[6]: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/html_frame_owner_element.cc;l=862-863;drc=6fd9edfbb85bc5fb2ed8f9300abe83cd03ab54b7
[7]: https://source.chromium.org/chromium/chromium/src/+/main:content/renderer/render_frame_impl.h;l=929-953;drc=5575ddb21068841ba19e1ea957b4fdb5adcd0250
[8]: https://source.chromium.org/chromium/chromium/src/+/main:content/renderer/render_view_impl.cc;l=290-292;drc=5dffcc4991ab32edc7dbc99c3b4685882c029ab0Bug: 1075729
Change-Id: I6c01ece280bc8702dda6ba60015eaafb3989f3d3
Reviewed-on: https://chromium-review.googlesource.com/3763042
WPT-Export-Revision: b83f79f5e17b45b986d38c0a607f602332188f1f
Assignee | ||
Updated•7 months ago
|
Assignee | ||
Comment 1•7 months ago
|
||
Pushed to try (stability) https://treeherder.mozilla.org/#/jobs?repo=try&revision=224083f123b8cc57b461dd72778cceb863303764
Assignee | ||
Comment 2•7 months ago
|
||
CI Results
Ran 0 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI
Total 1 tests and 3 subtests
Status Summary
Firefox
OK
: 1
PASS
: 1
FAIL
: 2
Chrome
OK
: 1
PASS
: 2
FAIL
: 1
Safari
OK
: 1
PASS
: 2
FAIL
: 1
Links
Details
Firefox-only Failures
- /html/browsers/windows/browsing-context.html [wpt.fyi]
- Check that browsing context has new, ready HTML document:
FAIL
- Check that browsing context has new, ready HTML document:
New Tests That Don't Pass
- /html/browsers/windows/browsing-context.html [wpt.fyi]
- Check that browsing context has new, ready HTML document:
FAIL
(Chrome:PASS
, Safari:PASS
) - Check the document properties corresponding to the creator browsing context:
FAIL
(Chrome:FAIL
, Safari:FAIL
)
- Check that browsing context has new, ready HTML document:
Pushed by wptsync@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/037f59b84ab1 [wpt PR 34879] - Fix document.referrer on about:blank creation, a=testonly
Comment 4•7 months ago
|
||
bugherder |
Description
•