28976 2009-09-04 09:59:14 -0700 element.hasAttribute() fails to return true for nodes imported from XML documents 2022-08-02 09:57:59 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) All All RESOLVED CONFIGURATION CHANGED http://www.robodesign.ro/coding/0063/ HasReduction P2 Normal --- 1 mihai.sucan webkit-unassigned ahmad.saleem792 ap bfulgham cdumez jchaffraix rniwa sam oldest_to_newest 144844 0 mihai.sucan 2009-09-04 09:59:14 -0700 The element.hasAttribute() fails to return true for imported nodes when the attribute includes upper case characters. Steps to reproduce: 1. Have two DOM documents, say DocA and DocB. 2. Import from DocA into DocB an element node which has at least one child element node. 3. Retrieve a reference to one of the child element nodes you imported. 4. Try element.hasAttribute('someAttributeWithUpperCase'). Expected result: the element.hasAttribute() method must return true if the attribute is set for the element node. Actual result: the element.hasAttribute() method returns false, even if the attribute is set for the said element node. What is more curious is that the element.getAttribute('someAttributeWithUpperCase') method works fine, and the attribute value is properly returned. It should be noted that if the attribute has no upper case letter, then the hasAttribute() method works as expected. Additionally, the importNode() step is crucial to exposing the bug. If you try hasAttribute() with pre-existing document elements which have attributes with upper case names, it all works fine. The URL points to a minimal test case which loads an XHTML document with XMLHttpRequest and imports the element node into the main document, and then tries the element.hasAttribute() method. The test case fails in Webkit (tested with Google Chrome 2 on Windows, Safari 4 on Windows, Chromium 4 development daily build on Linux). The test case does not fail in Opera 9.6, Opera 10, Firefox 3.0, Firefox 3.5 and Konqueror 4.1. 145263 1 ap 2009-09-07 22:22:47 -0700 Case sensitivity behavior is implemented differently for getAttribute() on one hand, and hasAttribute()/setAttribute()/removeAttribute()/getAttributeNode() on another. Which behavior is "right" may be subject to discussion, but having it different seems clearly wrong. 145479 2 ap 2009-09-08 12:03:18 -0700 See also: bug 20247 comment 10. 145515 3 39208 sam 2009-09-08 13:26:08 -0700 Created attachment 39208 Test case 1502836 4 lforschler 2019-02-06 09:02:45 -0800 Mass moving XML DOM bugs to the "DOM" Component. 1888364 5 ahmad.saleem792 2022-08-02 04:59:00 -0700 All browsers (Chrome Canary 106, Firefox Nightly 105 and Safari 15.6 on macOS 12.5) are showing "FAILED!" and I am not sure on Web-Spec so appreciate if someone can mark this bug accordingly. Thanks! 1888412 6 rniwa 2022-08-02 09:17:54 -0700 This is config changed now that Firefox's behavior is aligned with WebKit's. imported.hasAttributeNS(null, 'camelCase') returns true. 39208 2009-09-08 13:26:08 -0700 2009-09-08 13:26:08 -0700 Test case myVersion.html text/html 836 sam PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8Ym9keT4KICAgIDxwPmltcG9ydE5vZGUoKSArIGhhc0F0 dHJpYnV0ZSgpLjwvcD4KICAgIDxwcmUgaWQ9ImNvbnNvbGUiPjwvcHJlPgogICAgPHNjcmlwdD4K ICAgICAgICBmdW5jdGlvbiBsb2cobXNnKQogICAgICAgIHsKICAgICAgICAgICAgZG9jdW1lbnQu Z2V0RWxlbWVudEJ5SWQoJ2NvbnNvbGUnKS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVhdGVUZXh0 Tm9kZShtc2cgKyAiXG4iKSk7CiAgICAgICAgfQoKICAgICAgICBpZiAod2luZG93LmxheW91dFRl c3RDb250cm9sbGVyKQogICAgICAgICAgICBsYXlvdXRUZXN0Q29udHJvbGxlci5kdW1wQXNUZXh0 KCk7CgogICAgICAgIHZhciBuZXdEb2N1bWVudCA9IGRvY3VtZW50LmltcGxlbWVudGF0aW9uLmNy ZWF0ZURvY3VtZW50KCJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiwgImRpdiIsIG51bGwp OwogICAgICAgIHZhciBzcGFuID0gbmV3RG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic3BhbiIpOwog ICAgICAgIHNwYW4uc2V0QXR0cmlidXRlKCJjYW1lbENhc2UiLCAiZGF0YSIpOwogICAgICAgIG5l d0RvY3VtZW50LmRvY3VtZW50RWxlbWVudC5hcHBlbmRDaGlsZChzcGFuKTsKCiAgICAgICAgdmFy IGltcG9ydGVkID0gZG9jdW1lbnQuaW1wb3J0Tm9kZShzcGFuLCB0cnVlKTsKCiAgICAgICAgaWYg KGltcG9ydGVkLmhhc0F0dHJpYnV0ZSgnY2FtZWxDYXNlJykpIHsKICAgICAgICAgICAgbG9nKCdQ QVNTRUQhJyk7CiAgICAgICAgfSBlbHNlIHsKICAgICAgICAgICAgbG9nKCdGQUlMRUQhJyk7CiAg ICAgICAgfQogICAgPC9zY3JpcHQ+CjwvYm9keT4KPC9odG1sPgo=