RESOLVED WORKSFORME 22211
Accessing DOM elements via window.elementID should work in XHTML 
https://bugs.webkit.org/show_bug.cgi?id=22211
Summary Accessing DOM elements via window.elementID should work in XHTML
Raghu
Reported 2008-11-12 11:35:39 PST
In Gtk-Webkit browser, we are facing issues with respect to accessing DOM elements directly, without using getElementById() from inside javascripts. We have many XHTML pages written already, without using getElementById() and all the pages are perfectly working fine in Opera. As “Chrome” is built using webkit, I tried testing the pages on ‘Chrome’. To my surprise, the same files worked fine in ‘Chrome’. Then, I tried with Safari, (latest nightly updated), the behavior is same as Gtk-Webkit. It throws, “Can’t find variable: DOM element name”
Attachments
test XHTML page (927 bytes, application/xhtml+xml)
2008-11-12 11:37 PST, Raghu 		no flags
Details
test page (HTML) (787 bytes, text/html)
2008-11-12 11:38 PST, Raghu 		no flags
Details
HTML document (527 bytes, text/html)
2011-12-07 01:24 PST, ssseintr 		no flags
Details
XHTML document (771 bytes, application/xhtml+xml)
2011-12-07 01:25 PST, ssseintr 		no flags
Details
Img (111.79 KB, image/jpeg)
2011-12-07 01:26 PST, ssseintr 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Raghu
Comment 1 2008-11-12 11:37:29 PST
Created attachment 25099 [details] test XHTML page This is a XHTML test page! And it also display the result of test
Raghu
Comment 2 2008-11-12 11:38:49 PST
Created attachment 25100 [details] test page (HTML) This is a HTML test page! And it also display the result of test It succeeds in webkit. But, I am interrested in XHTML pages.
Raghu
Comment 3 2008-11-12 11:40:51 PST
If you just rename my test page from .xhtml to .html ... All works fine.
Simon Fraser (smfr)
Comment 4 2008-11-12 13:00:56 PST
I wonder if this is a quirks behavior.
Sam Weinig
Comment 5 2008-11-12 13:18:13 PST
This is not a quirks issue, but is due to this bit of code in JSDOMWindowBase::getOwnPropertySlot // Allow shortcuts like 'Image1' instead of document.images.Image1 Document* document = impl()->frame()->document(); if (document && document->isHTMLDocument()) { AtomicStringImpl* atomicPropertyName = AtomicString::find(propertyName); if (atomicPropertyName && (static_cast<HTMLDocument*>(document)->hasNamedItem(atomicPropertyName) || document->hasElementWithId(atomicPropertyName))) { slot.setCustom(this, namedItemGetter); return true; } } Presumably, the isHTMLDocument is return false for document in question. The reason this works in Chromium is because they have their own bindings to JS. In order to provide a cohesive product from this project, we really should try and stay bug for bug compatible. Though I am not sure this is actually a bug quite yet.
Maciej Stachowiak
Comment 6 2008-11-12 14:13:11 PST
For what it's worth, Firefox fails the XHTML version of the test, but it also fails the HTML version. Opera passes. IE is not testable because it does not support XHTML at all, but I am pretty sure it would pass the HTML version. For HTML, I think our choice to emulate the IE compat quirk is sound. For XHTML I could see an argument either way. PRO: HTML and XHTML should behave the same to the degree possible. CON: We shouldn't import this HTML quirk into XHTML (it makes programming tricky since you have unexpeced things in your global namespace), and since Firefox is the leading XHTML-based browser we should try to emulate them for XHTML content. Either way we should have this match between V8 and JSC based versions of WebKit.
Maciej Stachowiak
Comment 7 2008-11-12 14:13:46 PST
Might be good to bring up on the whatwg list to see if the HTML5 spec will have an opinion on this behavior for either HTML or XHTML.
Alexey Proskuryakov
Comment 8 2010-09-03 15:01:05 PDT
HTML5 currently says that this should work in XHTML. On the other side, Firefox only lets this work in quirks mode HTML, which generally seems like a safer and saner approach to me.
Adam Barth
Comment 9 2010-09-14 00:23:13 PDT
The JSC and V8 behavior appear to match. The XHTML version matches Firefox. Dumping junk in the global namespace is sad face, so I think we should keep our current behavior until we see broken sites.
Alexey Proskuryakov
Comment 10 2010-09-14 08:28:33 PDT
Adam, would you be willing to file a bug against HTML5 then? I couldn't convince Ian on IRC.
ssseintr
Comment 12 2011-12-07 01:23:56 PST
hi, Another issue I was facing is direct DOM access via "document" object. See, <body><img src='s.jpg' id='img1'/></body> If I access document.img1, webkit throws error, but other browsers like FireFox & Opera works without any problem for HTML & XHTML documents. Any suggestions..? Please refer the attachments for more info. Regards, Vicky.
ssseintr
Comment 13 2011-12-07 01:24:56 PST
Created attachment 118185 [details] HTML document
ssseintr
Comment 14 2011-12-07 01:25:34 PST
Created attachment 118186 [details] XHTML document
ssseintr
Comment 15 2011-12-07 01:26:02 PST
Created attachment 118187 [details] Img
Note You need to log in before you can comment on or make changes to this bug.