Opening a resource from the "Elements" tab does not apply <base> correctly
Reported by
dimitri....@gmail.com,
Mar 17 2016
|
|
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36 Steps to reproduce the problem: 1. Have a document with the following structure inside the <head> (in the given order: - A <script> tag with a relative URL, eg: <script src="foo.js"></script> - A <base> tag with HREF, eg. <base href="/bar/" /> - Another <script> tag with a relative URL, eg. <script src="baz.js"></script> 2. According to W3C, the <base> HREF should be added before any other resource that uses relative URLs. The result is that the first script should refer to foo.js, while the other script should refer to /bar/baz.js. This is also the behaviour of how Chrome loads the scripts 3. Open the "Elements" tab when viewing the page 4. Hover over the link from the first <script> tag, it incorrectly says http://localhost/bar/foo.js 5. Right click the link from the first <script> tag and select "Open link in new tab" 6. The wrong location (http://localhost/bar/foo.js) is opened What is the expected behavior? The expected behaviour is that the URL "http://localhost/foo.js" is opened, because the <base> tag should not be applied to the elements before the <base> tag. What went wrong? The wrong location "http://localhost/bar/foo.js" is opened. While I won't argue that the given HTML is invalid, it doesn't make sense that Chrome loads the resources correctly, but that the DevTools are showing the wrong URL. Did this work before? N/A Chrome version: 49.0.2623.87 Channel: stable OS Version: OS X 10.11.0 Flash Version: Shockwave Flash 21.0 r0 You can test it out on http://embed.plnkr.co/RXuFBefW2j98fj4hR4HZ/.
,
Mar 17 2016
True, I'm not arguing about that (I also mentioned it). But nonetheless it makes it hard to debug because of the weird result being displayed using the DevTools. |
|
►
Sign in to add a comment |
|
Comment 1 by caseq@chromium.org
, Mar 17 2016Status: WontFix (was: Unconfirmed)