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

Issue 649929 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , All , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Deeply nested phrasing content is parsed incorrectly

Reported by sin...@forlagetpropell.no, Sep 24 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/601.5.17 (KHTML, like Gecko) Version/9.1 Safari/601.5.17

Example URL:
http://codepen.io/somebee/pen/mAWBaq

Steps to reproduce the problem:
1. Write 5 levels of nested phrasing content (the nested tags must be of the same type, but it happens for any phrasing type).
<b><b><b><b><b>TEXT</b></b></b></b><i>TEXT</i></b>
See that this is parsed as expected.

2. Add any attribute to the outermost node:
<b title='top'><b><b><b><b>TEXT</b></b></b></b><i>TEXT</i></b>
See that any children except the first will be parsed outside of the outermost node.

What is the expected behavior?
Adding an attribute to a node should not make the html unwrap and restructure the fully valid html.

What went wrong?
Any children except the first will be parsed outside of the outermost node. See attached example.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? No 

Does this work in other browsers? No Safari Version 9.1 (11601.5.17.1)

Chrome version: 53.0.2785.116 (Official Build) (64-bit)  Channel: stable
OS Version: OS X 10.11.4
Flash Version: 

It works in Firefox and IE. Webkit (all versions of Safari/Webkit tested) has the same issue.
 
chromebug2.html
359 bytes View Download

Comment 1 by kojii@chromium.org, Sep 26 2016

Components: -Blink Blink>HTML>Parser
Labels: -OS-Mac OS-All
Status: Untriaged (was: Unconfirmed)
Cc: rnimmagadda@chromium.org
Labels: M-54 OS-Linux OS-Mac OS-Windows
Able to repro this issue on Windows 7, MAC (10.11.6) & Ubuntu Trusty (14.04) for Google Chrome Stable Version - 53.0.2785.116

This is a Non-Regression issue existing from M30 - # 30.0.1549.0
649929.mov
1.7 MB Download
Owner: kouhei@chromium.org
Status: Assigned (was: Untriaged)
Loading triager here. Assigning to Kouhei to take a look. Please reassign as necessary.

Comment 4 by phistuck@gmail.com, Oct 30 2016

Since Chrome, Safari and Internet Explorer 11 behave the same here (I have not tried Firefox or Edge, can anyone try?), it might actually be an HTML standard issue.
Unless Firefox or Edge behave differently, I suggest that you file an HTML issue at https://github.com/whatwg/html/issues (search for an existing one first, though) in order to propagate the fix to all of the browsers.
I will try it in Edge and report back. Does IE really behave the same way? I thought I tested it there when I filed the issue. It is definitely an issue from back WebKit (pre-blink). I also understand that it is probably not an issue people are constantly running into, but it popped up as a real problem here, and it took a long time to find out that it was in fact a browser issue. I tried searching through the spec to find out if it describes any sort of weird autoclosing etc that could make sense, but came up empty.
Labels: Hotlist-Interop
Yes, I can definitely reproduce with Internet Explorer 11.
I just checked Firefox and it behaves differently (both of the cases look the same).

Comment 7 by phistuck@gmail.com, Oct 31 2016

By the way, I suggest that you file an issue with WebKit as well at bugs.webkit.org and with Edge (if you can reproduce it there) at https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/ - filing bugs usually expedites vendor alignment a bit.

Comment 8 by geoff...@gmail.com, Dec 12 2016

I'm pretty sure this is a dupe of #268121, which links the WebKit and Edge bugs. This was a spec change a few years ago (2013).

Sign in to add a comment