Bug 88360 – createElement("image") creates an HTMLImageElement, although this hack should exist in parser only

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Boris Zbarsky]

This should create an HTMLElement with localName == "image".  Instead it creates an HTMLImageElement (with localName == "img").

Note that the hackery for <image> just happens in the parser in HTML5.  It doesn't affect the DOM.

Presto and Gecko get this right.  I haven't tested Trident.

[Alexey Proskuryakov]

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?

[Boris Zbarsky]

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.

[Alexey Proskuryakov]

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?

[Boris Zbarsky]

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.

[Rob Buis]

Created attachment 206180 [details]
Patch

[Sam Weinig]

Seems like the tests should be updated. Having them mysteriously fail doesn't seem that great.

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Rob Buis]

Created attachment 206190 [details]
Patch

[Rob Buis]

(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.

[Build Bot]

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

[Build Bot]

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

[Rob Buis]

Created attachment 206193 [details]
Patch

[Rob Buis]

Comment on attachment 206193 [details]
Patch

Clearing flags on attachment: 206193

Committed r152437: <http://trac.webkit.org/changeset/152437>

[Rob Buis]

All reviewed patches have been landed.  Closing bug.