document.anchors only returns anchors with a name attribute |
|||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36 Example URL: data:text/html,<!doctype html><a href="foo">bar</a><script>console.log(document.anchors)</script> Steps to reproduce the problem: 1. Go to the URL. 2. Press F12. 3. Expand the logged HTML Collection. What is the expected behavior? An element within the collection. What went wrong? No element within the collection. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes I do not remember Does this work in other browsers? Yes Chrome version: 49.0.2623.87 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: On the other hand, if Chrome got away with it, perhaps this is web compatible and others could follow. I doubt that, though.
,
Mar 18 2016
,
Mar 18 2016
Unable to reproduce the issue on windows 7 using chrome version 49.0.2623.87 and 51.0.2680.0 with the below steps 1. Go to URL data:text/html,<!doctype html><a href="foo">bar</a><script>console.log(document.anchors)</script> 2.Open Dev tools 3.Go to Properties 4.Able to see the HTML Collection Please find the attached screen shot and confirm anything missed here.Please suggest to bisect the issue further. Thank you!
,
Mar 18 2016
You are looking at the wrong object. Open the console. I logged an object there (document.anchors). Expand it - it is always empty.
,
Mar 18 2016
I see that there is an interoperability issue here. MDN says only anchor elements with a "name" attribute (<a name="...") are supposed to show up in the list. However, Internet Explorer 11 returns all of the anchor elements (<a href="..."). Since this has been removed from the specification, it might not better.
,
Mar 18 2016
,
Mar 20 2016
I am not sure this is a regression anymore.
,
Mar 20 2016
,
Mar 21 2016
Thanks for the update. Tested the issue on windows 7 using chrome version 49.0.2623.87 as per the comment #4.Unable to find the document.anchors object in console. Please find the attached screen shot for the same. could you please provide us any screen shot would help us for better understanding the issue. Thanks in advance!
,
Mar 21 2016
That logged HTMLCollection object you expanded is document.anchors...
,
Mar 21 2016
,
Mar 22 2016
Unable to reproduce the issue on windows 7 using chrome version 49.0.2623.87 with the below steps 1. Go to URL data:text/html,<!doctype html><a href="foo">bar</a><script>console.log(document.anchors)</script> 2.Open console document.anchors 3.Expanded the HTML Collection Unable to find the element attribute in the list of attributes.Compared with Firefox observed the same set of attributes. please provide us the screenshot to find the exact element which is missing in the list. Thanks,
,
Mar 22 2016
I mentioned that Internet Explorer 11 returns the element, not Firefox. But now I see that it does not. I now see the real difference. I amended the summary. Internet Explorer 11 returns anchors that have an ID attribute (<a id=foo>) as well as <a name=foo>, while Chrome and Firefox only return <a name=foo>. See the attached page (since data URLs do not work in Internet Explorer for top level frames). Note that in Internet Explorer 11, you must click on the "Allow blocked content" button in the information bar at the bottom in order to see the result in its console (F12). I do not have Edge to test and its behavior likely differs from Internet Explorer 11. If you can test it and the reports are the same as Chrome, this can be closed.
,
Mar 24 2016
I just tested Edge (using the Azure RemoteApp mechanism). It has not changed its behavior, still including <a id="..."> in document.anchors.
,
Mar 28 2016
tkent, can you triage this? Sounds like this is WontFix?
,
Mar 29 2016
The IE/Edge behavior looks more reasonable to me because id="..." works as an anchor. This is an interoperability issue, but low priority.
,
Apr 15 2016
,
Apr 15 2016
Perhaps this needs WHATWG HTML or DOM coordination, though, since Firefox does not follow the new behavior.
,
Apr 15 2016
So do you mean we need some discussion before jumping onto the implementation? I have already submitted a patch at https://codereview.chromium.org/1889793005/ :)
,
Apr 15 2016
In my opinion, whenever we find a difference in implementation that we want to change, we need to try and align all of the browsers (which means, at least starting a discussion) and make sure the new behavior is specified. Blindly changing stuff because we think it is more rational hurts interoperability.
,
Apr 15 2016
ok, i got it.
,
Apr 13 2017
,
Apr 16 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 23 2018
|
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by phistuck@chromium.org
, Mar 17 2016Labels: -Type-Bug -Pri-2 M-49 M-51 Pri-1 Type-Bug-Regression
Status: Untriaged (was: Unconfirmed)