Anchor navigation broken in data: documents
Reported by
bzbar...@mit.edu,
May 9 2018
|
||||
Issue descriptionChrome Version: 68.0.3423.2 (Official Build) dev (64-bit) OS: MacOS 10.12 What steps will reproduce the problem? (1) Load data:text/html,<a href="#foo">Click me</a><div style="height: 5000px"></div><div id="foo">I am here</div> (2) Click the link. What is the expected result? Scroll to the bottom. What happens instead? Nothing. Console says: Not allowed to navigate top frame to data URL: data:text/html,<a href="#foo This presumably broke when links to data: were disabled. But this case doesn't have the problems that was trying to address, since it's not changing the (user-entered) URL in the URL bar, apart from the anchor target bit.
,
May 9 2018
May also be related to changes with data URL anchors in issue 123004, which smcgruer@ is working on.
,
May 9 2018
No change has been made to data URL anchor parsing (that stayed committed, anyway - my one attempt was reverted in under 4 hours). Chrome continues to incorrectly parse '#' as both part of the body as well as indicating the fragment start. For the record, by spec your data URL should be: data:text/html,<a href="%23foo">Click me</a><div style="height: 5000px"></div><div id="foo">I am here</div>
,
May 9 2018
I confirmed with a bisect that this was changed by https://chromium.googlesource.com/chromium/src/+/ba52f56207a4b9d70b34880fbff2352e71a06422 That CL already checks for same document navigations [0], but the renderer side check (request.GetResourceRequest().IsSameDocumentNavigation()) incorrectly returns false for data URL anchor navigations, causing the blockage. That said, the change also broke data URLs linking to other URLs: data:text/html,<html><a href="data:text/html,another page">Link</a></html> This was intentional, as we didn't have a reliable way of getting the URL of the frame that initiated the navigation. So any renderer initiated navigation, whether initiated by a data URL or not, was blocked. [0] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/loader/frame_loader.cc?rcl=8e7c08d3d11c61d08ad05d3ebc283aa2d6bf7c91&l=721
,
Jul 27
Given that data: to data: navigations are already broken and that fixing this bug isn't currently possible (we are lacking information about the initiator origin), I'm going to mark it as WontFix. (We can consider reopening in the future if this technically becomes possible to fix)
,
Jul 27
That's a significant expansion of the scope of toplevel data: load blocking compared to what was announced, since it breaks basic user interaction with the already-loaded page...
,
Jul 27
That's true, but unfortunately out of process iframes made it virtually impossible to get the initiator information ( bug 651895 ). |
||||
►
Sign in to add a comment |
||||
Comment 1 by nasko@chromium.org
, May 9 2018Owner: mea...@chromium.org