1863202 - Interop bug with nested buttons via innerHTML

Status: RESOLVED INVALID

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Luke Warlow]

Steps to reproduce:

Load https://jsfiddle.net/1z43a8en/

Actual results:

You'll see an empty button, a button with the word Inner and then the text Outer. Repeated twice.

Expected results:

In Chrome and Safari: You'll see an empty button, a button with the word Inner and then the word Outer on the first line. On the second you'll see a button with a nested button with the word Inner, and then the word Outer still inside of the parent button.

I'm not sure who is correct but seeing as Firefox is the odd one out I thought I'd raise it here.

Comment 1

[Luke Warlow]

Attachment: firefox.png

Comment 2

[Luke Warlow]

Attachment: chrome-safari.png

Comment 3

[Robert Longson [:longsonr]]

Well it's not valid to nest buttons in the first place per https://html.spec.whatwg.org/multipage/form-elements.html#the-button-element

Phrasing content, but there must be no interactive content descendant...

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The test cases of bug 76616 and this bug look very different.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

What's the expected behavior of setting innerHTML to the source containing nested-elements which cannot be nested at loading?

Comment 7

[Henri Sivonen (:hsivonen)]

Looking at what the test case does, in Firefox, the fragment parsing works with div context the way it works within div is full-document parse. In Chrome, the result is different in fragment parse. This looks more like a parser bug that Chrome has inherited from WebKit.