Bug 88360 - createElement("image") creates an HTMLImageElement, although this hack should exist in parser only
Summary: createElement("image") creates an HTMLImageElement, although this hack should...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P4 Minor
Assignee: Rob Buis
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-05 13:27 PDT by Boris Zbarsky
Modified: 2013-07-06 13:09 PDT (History)
9 users (show)

See Also:


Attachments
Patch (4.96 KB, patch)
2013-07-05 18:36 PDT, Rob Buis
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from webkit-ews-05 for mac-mountainlion (525.16 KB, application/zip)
2013-07-05 22:59 PDT, Build Bot
no flags Details
Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2 (500.01 KB, application/zip)
2013-07-06 06:41 PDT, Build Bot
no flags Details
Patch (7.17 KB, patch)
2013-07-06 07:30 PDT, Rob Buis
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from webkit-ews-06 for mac-mountainlion (511.23 KB, application/zip)
2013-07-06 10:48 PDT, Build Bot
no flags Details
Patch (7.90 KB, patch)
2013-07-06 11:13 PDT, Rob Buis
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Boris Zbarsky 2012-06-05 13:27:46 PDT
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.
Comment 1 Alexey Proskuryakov 2012-06-05 15:03:51 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?
Comment 2 Boris Zbarsky 2012-06-05 18:35:26 PDT
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.
Comment 3 Alexey Proskuryakov 2012-06-05 23:02:26 PDT
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?
Comment 4 Boris Zbarsky 2012-06-05 23:14:51 PDT
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.
Comment 5 Rob Buis 2013-07-05 18:36:23 PDT
Created attachment 206180 [details]
Patch
Comment 6 Sam Weinig 2013-07-05 21:17:59 PDT
Seems like the tests should be updated. Having them mysteriously fail doesn't seem that great.
Comment 7 Build Bot 2013-07-05 22:59:01 PDT
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
Comment 8 Build Bot 2013-07-05 22:59:03 PDT
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 9 Build Bot 2013-07-06 06:41:25 PDT
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
Comment 10 Build Bot 2013-07-06 06:41:27 PDT
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
Comment 11 Rob Buis 2013-07-06 07:30:29 PDT
Created attachment 206190 [details]
Patch
Comment 12 Rob Buis 2013-07-06 07:31:55 PDT
(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 13 Build Bot 2013-07-06 10:48:43 PDT
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
Comment 14 Build Bot 2013-07-06 10:48:44 PDT
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
Comment 15 Rob Buis 2013-07-06 11:13:33 PDT
Created attachment 206193 [details]
Patch
Comment 16 Rob Buis 2013-07-06 13:09:42 PDT
Comment on attachment 206193 [details]
Patch

Clearing flags on attachment: 206193

Committed r152437: <http://trac.webkit.org/changeset/152437>
Comment 17 Rob Buis 2013-07-06 13:09:57 PDT
All reviewed patches have been landed.  Closing bug.