Issue metadata
Sign in to add a comment
|
Parsed XML document, incorrect find of elements *which have a namespace*
Reported by
jnbarc...@gmail.com,
Jun 30 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: Run my JSFiddle: https://jsfiddle.net/a504caa0/ See also my StackOverflow post: https://stackoverflow.com/questions/43607774/chrome-incorrect-jquery-find-on-xml-result I have received no solutions there, and am trying raising this directly in a Chrome forum in the hope of some comment/workaround/fix. The code: <!DOCTYPE html> <html> <head> <script src="https://code.jquery.com/jquery-3.2.1.js"></script> </head> <body> <script> $(function () { var xml = '<?xml version="1.0"?>' + '<DataSet>' + ' <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">' + ' <xs:element>' + ' </xs:element>' + ' </xs:schema>' + '</DataSet>' ; var xmlDoc = $.parseXML(xml) var $docElm = $(xmlDoc.documentElement); alert("> find('xs\\:schema').length=" + $docElm.find('> xs\\:schema').length); alert("find('xs\\:schema').length=" + $docElm.find('xs\\:schema').length); alert("> find('xs\\:schema').find('> xs\\:element').length=" + $docElm.find('> xs\\:schema').find('> xs\\:element').length); alert("> find('xs\\:schema').find('xs\\:element').length=" + $docElm.find('> xs\\:schema').find('xs\\:element').length); }); </script> </body> </html> What is the expected behavior? The message boxes which come up should show 1 match for each of the 4 "find()s" on the XML document. That is the behaviour in Firefox & IE 11. What went wrong? In Chrome only, 2 of the "find()"s incorrectly return 0 matches. It appears that: $elm.find('xs\\:schema') does not work as it should. Note that this a *deep* traversal attempting to find a node *with a namespace*. For comparison, both of the following *do* work in Chrome: $elm.find('> xs\\:schema') # leading ">" means direct child only, not deep $elm.find('schema') # no leading "xs\\:" means no namespace Did this work before? N/A Chrome version: 59.0.3071.115 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: I am hoping for confirmation that this is incorrect behaviour in Chrome and/or a workaround so that the software I am developing can be released working under Chrome.
,
Jul 3 2017
,
Jul 4 2017
Thanks for filing the issue, rechecked the issue on chrome Beta # 60.0.3112.50 & canary version 60.0.3147.0 on Windows 10 and MAC 10.12.5, Observed that all the alerts generated show 1 match for each of the 4 "find()s. Request you to please check on the Beta & Canary version and let us know if this is the expected output. Thanks.!
,
Jul 4 2017
Just to update, used the test link https://jsfiddle.net/a504caa0/ to replicate the issue. Missed to include in the previous comment. Thanks.!
,
Jul 4 2017
Thank you. I find it surprising that this bug would just have been fixed after many years of being in Chrome. Rather than making me fetch a Beta version of Chrome, would you be kind enough to check behaviour for you on the current released version of Chrome I am using, 59.0.3071.115. If you claim it is also working there, then we are not looking at the same thing/seeing the same behaviour....
,
Jul 4 2017
Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 4 2017
@ jnbarchan: Thanks for the update, I did check on the stable version 59.0.3071.115 and I observe that I get an alternate 1,0,1,0 results for the 4 "find()s. Where as on on Beta# i get 1,1,1,1 for the 4 "find()s. Just an FYI, Beta is going to be pushed to stable soon. Also I see the same result of Firefox, which was observed on beta# 60.0.3112.50. Thanks.!
,
Jul 4 2017
@ ranjitkan Wow, what a coincidence that this issue has literally just been fixed! I don't really want to install a Beta, I do support for my customers and it's important I am on same version as they are. I shall wait till I see Release #60 and then return to this issue and check behaviour. Thank you.
,
Jul 4 2017
Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 6 2017
Tested on Chrome Stable #59.0.3071.115 on Windows 10 and issue is reproduced. However, in Canary #61.0.3149.0, Dev #61.0.3141.7 and in Chrome Beta #60.0.3112.50 it is as expected. Using the reverse bisect providing the bisect results, Good Build:60.0.3101.0 (Revision:471958). Bad Build:60.0.3100.0 (Revision:470111). You are probably looking for a change made after 471640 (known good), but no later than 471643 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/fc3bf0e63c552b01af736044b48f3a44a3e5b8be..5025bccfe31b6c49a1e868d58568a89c75b3f338 Review-URL: https://codereview.chromium.org/2868823002 @foolip: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to owner concerned. Also adding the shanmuga.m@samsung.com in CC who is related to the issue. Observations: Issue is reproduced on Mac 10.12.5 and Ubuntu 14.04.
,
Jul 6 2017
Updated Status to Assigned.
,
Jul 6 2017
I'm about to go on vacation, so I'll have to bounce this to tkent.
,
Jul 11 2017
This was already fixed. Google Chrome v60 will have the fix. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by jnbarc...@gmail.com
, Jun 30 2017