In documents created dynamically using DOMParser, <base> tags with protocol-relative href attribute are ignored
Reported by
matma.rex@gmail.com,
Jul 5 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.20 Safari/537.36 OPR/47.0.2631.7 (Edition beta) Steps to reproduce the problem: Download the attached test case, start a localhost server and view it; or run the below in your browser console: html = '<!DOCTYPE html><html><head><base href="//example.com/"/></head><body><a href="./foo">foo</a></body></html>'; doc = new DOMParser().parseFromString( html, 'text/html' ); console.log( doc.getElementsByTagName( 'a' )[ 0 ].href ); What is the expected behavior? Expected output: http://example.com/foo What went wrong? Actual output: http://localhost/foo Did this work before? N/A Does this work in other browsers? Yes Chrome version: 60.0.3112.20 Channel: n/a OS Version: 10.0 Flash Version: In documents created dynamically using DOMParser, <base> tags with protocol-relative href attribute are apparently ignored. This causes <a> tags' href property to resolve relative to the current document rather than the given base. Note that the issue does not occur if you just view the document with such <base> tag directly. Downstream issue: https://phabricator.wikimedia.org/T167936
,
Jul 5 2017
,
Jul 27 2017
,
Jul 31 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/70aec2eeffa34055bf79a884a564db0be2368ab1 commit 70aec2eeffa34055bf79a884a564db0be2368ab1 Author: Kent Tamura <tkent@chromium.org> Date: Mon Jul 31 03:46:03 2017 BASE element: Fix relative href handling in about:blank documents. According to the specification, relative URL of base[href] should be resolved with document's fallback base URL, not document's URL. Bug: 739504 Change-Id: I811e8b14d7130873a4ffa6d45a094407f9e8a098 Reviewed-on: https://chromium-review.googlesource.com/590632 Reviewed-by: Hayato Ito <hayato@chromium.org> Commit-Queue: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/master@{#490705} [delete] https://crrev.com/3d83f26ad153fd480b6e2330a90c5ba37f4dd623/third_party/WebKit/LayoutTests/external/wpt/html/infrastructure/urls/terminology-0/document-base-url-expected.txt [delete] https://crrev.com/3d83f26ad153fd480b6e2330a90c5ba37f4dd623/third_party/WebKit/LayoutTests/external/wpt/html/semantics/document-metadata/the-base-element/base_about_blank-expected.txt [delete] https://crrev.com/3d83f26ad153fd480b6e2330a90c5ba37f4dd623/third_party/WebKit/LayoutTests/external/wpt/html/semantics/document-metadata/the-base-element/base_srcdoc-expected.txt [modify] https://crrev.com/70aec2eeffa34055bf79a884a564db0be2368ab1/third_party/WebKit/LayoutTests/html/document_metadata/base-expected.txt [modify] https://crrev.com/70aec2eeffa34055bf79a884a564db0be2368ab1/third_party/WebKit/LayoutTests/html/document_metadata/base.html [modify] https://crrev.com/70aec2eeffa34055bf79a884a564db0be2368ab1/third_party/WebKit/Source/core/dom/Document.cpp [modify] https://crrev.com/70aec2eeffa34055bf79a884a564db0be2368ab1/third_party/WebKit/Source/core/html/HTMLBaseElement.cpp
,
Jul 31 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by rkatt...@wikimedia.org
, Jul 5 2017When a DOMParser-ed document had a protocol-relative base URI, that used to be invalid because there was no parent document to inherit a protocol from, and doc.baseURI was null. This was arguably annoying, but at least it was consistent. The new behavior is inconsistent: a protocol-relative base URI is ignored (as if there is no parent document to inherit from / resolve against), but doc.baseURI is set to the base URI of the viewport document (so clearly there is a parent document). Interestingly, doing baseNode = doc.getElementsByTagName('base')[0]; baseNode.href = baseNode.href; works around the issue. The latter statement is not a no-op, but causes the protocol-relative base URI to be resolved against the parent document's base URI.