Summary: | createElement("image") creates an HTMLImageElement, although this hack should exist in parser only | ||
---|---|---|---|
Product: | WebKit | Reporter: | Boris Zbarsky <bzbarsky> |
Component: | DOM | Assignee: | Rob Buis <rwlbuis> |
Status: | RESOLVED FIXED | ||
Severity: | Minor | CC: | abarth, ap, buildbot, commit-queue, esprehn+autocc, ian, rniwa, rwlbuis, sam |
Priority: | P4 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Attachments: |
Description
Boris Zbarsky
2012-06-05 13:27:46 PDT
We have a number of aliases for elements (like ins/mod), but this is the only one affected AFAICT. It would be surprising if it mattered at all what document.createElement("image").localName returns. Boris, are you aware of any affected content? The localName wasn't the problem. The problem is the HTMLImageElement vs HTMLElement. Until a few days ago, the WebGL conformance test suite actually relied on this bug to pass in WebKit-based browsers... It's been fixed since, which is how I ran into this issue. OK, renaming the bug further. Curiously, Firefox 13 does this: [22:56:55.593] < document.createElement("image") [22:56:55.596] > [object HTMLSpanElement] -- [22:58:20.329] < document.createElement("foobar") [22:58:20.331] > [object HTMLUnknownElement] WebKit behavior is both closer to current spec and more logical, so why don't we specify what WebKit does? The HTMLSpanElement string bit is just a (known) bug slated to be fixed. The only affected part is the toString behavior, since there is no separate interface for spans.
> WebKit behavior is both closer to current spec
No, it's not. The current spec calls for creating an HTMLElement. Which happens to have the same DOM API as what Gecko creates, but not as what WebKit creates.
Created attachment 206180 [details]
Patch
Seems like the tests should be updated. Having them mysteriously fail doesn't seem that great. Comment on attachment 206180 [details] Patch Attachment 206180 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/1045064 New failing tests: fast/canvas/webgl/context-lost.html Created attachment 206186 [details]
Archive of layout-test-results from webkit-ews-05 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-05 Port: mac-mountainlion Platform: Mac OS X 10.8.3
Comment on attachment 206180 [details] Patch Attachment 206180 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/1017821 New failing tests: fast/canvas/webgl/context-lost.html Created attachment 206189 [details]
Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-11 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.3
Created attachment 206190 [details]
Patch
(In reply to comment #6) > Seems like the tests should be updated. Having them mysteriously fail doesn't seem that great. Agreed, I updated the tests themselves now as well. Comment on attachment 206190 [details] Patch Attachment 206190 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/909438 New failing tests: fast/canvas/webgl/context-lost.html Created attachment 206192 [details]
Archive of layout-test-results from webkit-ews-06 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-06 Port: mac-mountainlion Platform: Mac OS X 10.8.3
Created attachment 206193 [details]
Patch
Comment on attachment 206193 [details] Patch Clearing flags on attachment: 206193 Committed r152437: <http://trac.webkit.org/changeset/152437> All reviewed patches have been landed. Closing bug. |