New issue
Advanced search Search tips

Issue 648712 link

Starred by 7 users

Issue metadata

Status: Duplicate
Merged: issue 647151
Owner: ----
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Compat



Sign in to add a comment

Parent stylesheet referenced by child frame unloads style from parent

Reported by dwe...@sapiosciences.com, Sep 20 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Have a parent page reference a stylesheet via a link tag.
2. Have this same parent page contain an iframe pointing to a child page.
3. Have this child page reference the same style sheet as the parent page.
4. Load the parent page (which will load the child page i the iframe).
5. Refresh the parent page (soft-refresh -- let it use the cache).

What is the expected behavior?
The style rules should apply to both the page and the child page after the refresh.

What went wrong?
Upon initial load, both the parent and the child had the stylesheet rules applied.

After refreshing the page, only the child page has the style rules applied.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? Yes v52

Does this work in other browsers? Yes 

Chrome version: 53.0.2785.116  Channel: stable
OS Version: 6.3
Flash Version: 

I have attached a simple example of the problem.  Host these files from a webserver and load outer.htm in Chrome.  Both the outer and the inner pages will be blue.  Then refresh the page.  Now only the inner frame is blue.

If you rapidly resize the browser window, the style will sometimes get re-applied to the parent.

I have seen this same issue in a larger (private) web application.  In that case, the outer frame has its style applied and works as intended.  The iframe is created dynamically at some future time and inserted into the document.  When this child frame (which references the same style sheet as the parent) is loaded from cache, the stylesheet is no longer applied to the parent document.
 
outer.htm
191 bytes View Download
inner.htm
156 bytes View Download
style.css
65 bytes View Download

Comment 1 by rmmh@google.com, Sep 20 2016

The same problem occurs if two tabs share the same process and both reference the same stylesheet.

Here's another repro: http://chrome-glitch.appspot.com/
Components: Blink>CSS

Comment 3 by suzyh@chromium.org, Sep 21 2016

Labels: Needs-TestConfirmation
For the example in comment #1, I don't know how to set it up such that the two tabs share the same process, so cannot repro.

For the example attached to the original report, I downloaded the three files and served them by running "python -m SimpleHTTPServer" in the download directory and navigating to localhost:8000/outer.htm. For me in both Stable and Canary (v53 and v55) both frames remain blue.

I'm marking this as Needs-TestConfirmation since I am unable to repro.

Comment 4 by rmmh@google.com, Sep 21 2016

I'm seeing this consistently on 53.0.2785.116 (64-bit) on Ubuntu.

The easiest way to get the two tabs in the same process is to open the glitch side in a new incognito window, not shared with any other tabs. Then, middle-click to open a new tab. At this point the Task Manager should show both tabs under the same PID, with a vertical line instead of a dot on the left side showing the sharing.

Click to reload the first tab, then click to reload the second tab. The blue bar will disappear from the first tab as the CSS is unloaded.

Comment 5 by suzyh@chromium.org, Sep 21 2016

Labels: -Needs-TestConfirmation Needs-Bisect
Status: Untriaged (was: Unconfirmed)
Aha, the issue in comment #1 appears to be the same as  issue 649100  and following the instructions there to create the two tabs in the same process with Duplicate, I was able to repro on both Linux and Windows. I'll dupe  issue 649100  against this one.

Comment 6 by suzyh@chromium.org, Sep 21 2016

Cc: thakis@chromium.org cbiesin...@chromium.org
 Issue 649100  has been merged into this issue.

Comment 7 by rmmh@google.com, Sep 21 2016

I can't repro this on 2785.89. Scanning the commits between .89 and .116, this commit looks suspicious: https://chromium.googlesource.com/chromium/src/+/f72812fd4fc8d47803ecb6921e4e78c762ecf56f

Comment 8 by suzyh@chromium.org, Sep 22 2016

Labels: Hotlist-Interop

Comment 9 by thakis@chromium.org, Sep 22 2016

Can you repro with the steps from the dupe?
Mergedinto: 647151
Status: Duplicate (was: Untriaged)
Sounds like a dupe of 647151 (and regression range matches too).

Sign in to add a comment