New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 796305 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Unexpected nesting when assigning non-HTML empty elements to innerHTML

Reported by khop...@gmail.com, Dec 19 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Steps to reproduce the problem:
1. Open up the Javascript console (Ctrl+Shift+J)

2. Enter the following commands:

  blah = document.createElement("blah");
  blah.innerHTML = `<one/><two/><three/>`;
  blah.outerHTML;

3. Actual results: See output on final command as

  "<blah><one><two><three></three></two></one></blah>"

What is the expected behavior?
Expected results:

  "<blah><one/><two/><three/></blah>"

These results would also be acceptable:

  "<blah><one></one><two></two><three></three></blah>"

What went wrong?
When assigning innerHTML, empty elements (elements that close themselves rather than having a separate closing tag, e.g. `<x/>` vs <x></x>`) are assumed to not be empty, resulting in improper nesting.

Did this work before? No 

Chrome version: 63.0.3239.84  Channel: n/a
OS Version: Debian Chromium
Flash Version: 

There must be something special about <br> and <img> because this works:

  blah = document.createElement("blah");
  blah.innerHTML=`<img/><img><br/>`;
  blah.outerHTML;

-> "<blah><img><img><br></blah>"

(I expected "<blah><img/><img>/><br/></blah>" but this does reinforce the internal knowledge about *specific* empty elements, which I assume should help parsing when missing the trailing slash.)
 

Comment 1 by khop...@gmail.com, Dec 19 2017

Also a bug in Mozilla Core/Firefox:

https://bugzilla.mozilla.org/show_bug.cgi?id=1426224

Comment 2 by woxxom@gmail.com, Dec 19 2017

The auto-closing tags are supported only on void elements as per the specification.
<img> and <br> are known void elements which is why the code works.
<one> and <two> and <three> are not known.

Comment 3 Deleted

Able to reproduce the issue on reported chrome version 63.0.3239.84 and on the latest canary 65.0.3299.0 using windows 10, Ubuntu 14.04 and Mac 10.12.6. As the issue is seen from M(50) 50.0.2661.0 considering it as non-regression and marking it as Untriaged.
Cc: viswatej...@techmahindra.com sc00335...@techmahindra.com
Labels: M-65 Needs-Triage-M63 Triaged-ET OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)

Comment 6 by f...@opera.com, Dec 20 2017

Status: WontFix (was: Untriaged)
As mentioned in c#2, this is working as intended. HTML (unlike XML) does not have the concept of "self-closing" or "empty" elements, so this is really a parse error from the parsers PoV, except for the few void elements where it is ignored entirely and for "foreign content" (SVG or MathML.)

The following section talks a bit about this particular error, and shows an example:

https://html.spec.whatwg.org/multipage/parsing.html#parse-error-non-void-html-element-start-tag-with-trailing-solidus

For more information on how the HTML parser deals with these cases, you can start from:

https://html.spec.whatwg.org/multipage/parsing.html#self-closing-flag

Sign in to add a comment