We are also facing the issue. CSS styles are getting removed for the previous frames when loading a new frame.

Attaching the test files which needs to be placed in a webserver with Web content cache as "Cache-Control: no-cache"

Deleted: Chrome Issue.mp4 1.9 MB

	Chrome Issue.mp4 1.9 MB View Download

Deleted: Chrome issue.zip 1.1 KB

Chrome issue.zip 1.1 KB Download

Title of bug is wrong, it must be without not: no-cache stylesheets are lost between two frames.

When using a max-age instead of no-cache it is working.

Another observation: When content is compressed it is working fine. So adding compression="force" for e.g. tomcat seems a workaround:

    <Connector port="80" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" compression="force"/>

Workaround with compression does not work in all situations, because proxy servers can offload the compression.

Also when max-age is set to e.g. 30, same issue occurs after about 120 seconds!

Can someone tell how I can increase priority of this issue? 

Created a filter which removes server side the "If-Modified-Since" and "If-None-Match" header, and apply this to css files so no 304 will be returned but a 200. Put it in the WEB-INF/lib directory of your application and restart web/application server as workaround. 

Deleted: chromeworkaround.jar 3.0 KB

chromeworkaround.jar 3.0 KB Download

The best workaround I found is to remove server side the following headers when css files are requested:

If-Modified-Since
If-None-Match

Added solution for servlet containers above. For apache similair way can be used, see: http://stackoverflow.com/a/20867608/227061. Probably for IIS also something like that can be done.

Previous workaround does not work when Proxy servers use "ETag" or "Last-Modified" to serve the page with a 304 from their own cache. Attached chromeworkaroundproxy jar solves this by removing these headers.

Deleted: chromeworkaroundproxy.jar 4.2 KB

chromeworkaroundproxy.jar 4.2 KB Download

I think this bug is pretty important, because it surfaces after some time with max-age and depends on state of the cache and only for css files (as far as I know now). So users get strange pages and it is pretty difficult to find out where it comes from. 

Can someone of the chromium project please look into this?

Probably duplicates of this ticket:
- https://bugs.chromium.org/p/chromium/issues/detail?id=648023
- https://bugs.chromium.org/p/chromium/issues/detail?id=648057

Hi @chrome team: This is effecting our daily activities. Please look into this ASAP. 

I can reproduce a variant of this on codereview.chromium.org which only uses max-age, but we seem to be requesting it with max-age=0.

Flipping between two tabs causes the styles.css to be lost.


Bumping priority and ccing current loading triager.

This definitely seems like a MemoryCache issue.

Unfortunately the repro stopped working for me. I think the request headers adding max-age=0 were the cause of this, but I'm not sure where that was coming from.

@csharrison: Did the attached reproduction scenario not work for you? Also take care to have no compression enabled (because then it will not occur).

I haven't had time to run the attached repro. If I have some time today I'll try to get to it.

 Issue 648057  has been merged into this issue.

 Issue 648023  has been merged into this issue.

Confirmed repro on 53.0.2785.116 (Official Build) (64-bit) Linux

attached: golang http server which serves local files w/ "Cache-Control: no-cache"

Deleted: serve.go 365 bytes

serve.go 365 bytes View Download

Still repros on ToT

Chromium	55.0.2866.0 (Developer Build) (64-bit)
Revision	cfc30f28e0bb2b16793188e670f109d81c8f153d-refs/heads/master@{#419610}
OS	Linux 

The root cause is that {CSS,XSL}StyleSheetResource::notifyFinished doesn't call markClientFinished on their clients.
Fix working locally. I'll upload the fix after writing layout test.

Probably regressed here:
https://codereview.chromium.org/2308393002/patch/1/10006

Thx for finding root cause.

Can this fix be make available in GA build i.e. Chrome 53??

Issue 646549 has been merged into this issue.

CL: https://codereview.chromium.org/2353903002

Same problem here while using `expires -1` on nginx, however, if there are multiple CSS, only the last one seems to be problematic. 

While the problem is fixed and released, what would be the recommended workaround on the server side? 

- Set a large cache value? It seems to only delay the bug.
- Ignore some browser requests headers?
- Adding a random URL parameter (http://foo.bar/file.css?c=random)?

 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3598c8bc9c56409f7c239c377fe6e42786d6aaa0

commit 3598c8bc9c56409f7c239c377fe6e42786d6aaa0
Author: kouhei <kouhei@chromium.org>
Date: Wed Sep 21 03:54:33 2016

{CSS,XSL}StyleSheetResource should mark their clients as finished on checkNotify

Before this CL, {CSS,XSL}StyleSheetResource::checkNotify didn't trigger markClientFinished as Resource::checkNotify did.
This CL aligns {CSS,XSL}StyleSheetResource::checkNotify to trigger it properly.

BUG= 647151 

Review-Url: https://codereview.chromium.org/2353903002
Cr-Commit-Position: refs/heads/master@{#419969}

[add] https://crrev.com/3598c8bc9c56409f7c239c377fe6e42786d6aaa0/third_party/WebKit/LayoutTests/http/tests/loading/css-no-cache-revalidation-expected.txt
[add] https://crrev.com/3598c8bc9c56409f7c239c377fe6e42786d6aaa0/third_party/WebKit/LayoutTests/http/tests/loading/css-no-cache-revalidation.html
[add] https://crrev.com/3598c8bc9c56409f7c239c377fe6e42786d6aaa0/third_party/WebKit/LayoutTests/http/tests/loading/resources/no-cache-css.php
[add] https://crrev.com/3598c8bc9c56409f7c239c377fe6e42786d6aaa0/third_party/WebKit/LayoutTests/http/tests/loading/resources/no-cache-xslt.php
[add] https://crrev.com/3598c8bc9c56409f7c239c377fe6e42786d6aaa0/third_party/WebKit/LayoutTests/http/tests/loading/resources/reference-css-no-cache.xhtml
[modify] https://crrev.com/3598c8bc9c56409f7c239c377fe6e42786d6aaa0/third_party/WebKit/Source/core/fetch/CSSStyleSheetResource.cpp
[modify] https://crrev.com/3598c8bc9c56409f7c239c377fe6e42786d6aaa0/third_party/WebKit/Source/core/fetch/XSLStyleSheetResource.cpp

Hi @Chrome team,

When can we expect this fix as part of Chrome 53 GA??

 Issue 645119  has been merged into this issue.

#29 I'll ask for beta -> stable merge once the metric look sane after Canary release.

This fix worked for us. We're hoping it can get merged into 53 asap.

Does this bug also refer to: CSS styles are cleared for current page when opening link in new tab or opening a new window

https://bugs.chromium.org/p/chromium/issues/detail?id=648237

Adding govind@ for FYI about M53 regression.

I posted a me-too comment in 648237. This fix worked for us as well.  Ditto for getting this into 53! 

 Issue 648712  has been merged into this issue.

 Issue 648237  has been merged into this issue.

 Issue 646395  has been merged into this issue.

Re #31, how is this change looking in Canary?

Is the changes(fix) already present in Canary build? I ma validating in Canary(Version 55.0.2867.0). Still the issue is present.

#41 - No, 2868 and later.

We have validated in Canary(Version 55.0.2868.0) and fix is working fine. Waiting for the stable release 53.

When can we except Chrome 53 with this fix?

I have also validated fix is working for our app in Canary 2868.

Please can I request this fix be deployed to Chrome 53?

The issue is causing terrible grief for users of our system.

[Automated comment] Request affecting a post-stable build (M53), manual review required.

Per kouhei@ reply on internal mail thread, this bug affects to all os.

This breaks all kinds of web pages.

This breaks many pages across the Web. Increasing priority.

Approving merge to M53 branch 2785 based on comment #43 and #44. Please merge ASAP. 

Also please request a merge to M54.

Issue 647093 has been merged into this issue.

Merge pushed to M53 2785.
Would you approve merge to M54 too?

bustamante@ for M54 approval.

Your change meets the bar and is auto-approved for M54 (branch: 2840)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/58cdb2e94ed67c3f5655d630fcacf1a26bcd203f

commit 58cdb2e94ed67c3f5655d630fcacf1a26bcd203f
Author: Kouhei Ueno <kouhei@chromium.org>
Date: Fri Sep 23 00:15:53 2016

{CSS,XSL}StyleSheetResource should mark their clients as finished on checkNotify

Before this CL, {CSS,XSL}StyleSheetResource::checkNotify didn't trigger markClientFinished as Resource::checkNotify did.
This CL aligns {CSS,XSL}StyleSheetResource::checkNotify to trigger it properly.

BUG= 647151 

Review-Url: https://codereview.chromium.org/2353903002
Cr-Commit-Position: refs/heads/master@{#419969}
(cherry picked from commit 3598c8bc9c56409f7c239c377fe6e42786d6aaa0)

Review URL: https://codereview.chromium.org/2362103002 .

Cr-Commit-Position: refs/branch-heads/2785@{#915}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[add] https://crrev.com/58cdb2e94ed67c3f5655d630fcacf1a26bcd203f/third_party/WebKit/LayoutTests/http/tests/loading/css-no-cache-revalidation-expected.txt
[add] https://crrev.com/58cdb2e94ed67c3f5655d630fcacf1a26bcd203f/third_party/WebKit/LayoutTests/http/tests/loading/css-no-cache-revalidation.html
[add] https://crrev.com/58cdb2e94ed67c3f5655d630fcacf1a26bcd203f/third_party/WebKit/LayoutTests/http/tests/loading/resources/no-cache-css.php
[add] https://crrev.com/58cdb2e94ed67c3f5655d630fcacf1a26bcd203f/third_party/WebKit/LayoutTests/http/tests/loading/resources/no-cache-xslt.php
[add] https://crrev.com/58cdb2e94ed67c3f5655d630fcacf1a26bcd203f/third_party/WebKit/LayoutTests/http/tests/loading/resources/reference-css-no-cache.xhtml
[modify] https://crrev.com/58cdb2e94ed67c3f5655d630fcacf1a26bcd203f/third_party/WebKit/Source/core/fetch/CSSStyleSheetResource.cpp
[modify] https://crrev.com/58cdb2e94ed67c3f5655d630fcacf1a26bcd203f/third_party/WebKit/Source/core/fetch/XSLStyleSheetResource.cpp

Pushed to M54 (branch: 2840)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/54c7dbb6ffaf423ca61bf7382db7a506b4b759df

commit 54c7dbb6ffaf423ca61bf7382db7a506b4b759df
Author: Kouhei Ueno <kouhei@chromium.org>
Date: Fri Sep 23 00:24:54 2016

{CSS,XSL}StyleSheetResource should mark their clients as finished on checkNotify

Before this CL, {CSS,XSL}StyleSheetResource::checkNotify didn't trigger markClientFinished as Resource::checkNotify did.
This CL aligns {CSS,XSL}StyleSheetResource::checkNotify to trigger it properly.

BUG= 647151 

Review-Url: https://codereview.chromium.org/2353903002
Cr-Commit-Position: refs/heads/master@{#419969}
(cherry picked from commit 3598c8bc9c56409f7c239c377fe6e42786d6aaa0)

Review URL: https://codereview.chromium.org/2362983002 .

Cr-Commit-Position: refs/branch-heads/2840@{#504}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[add] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/LayoutTests/http/tests/loading/css-no-cache-revalidation-expected.txt
[add] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/LayoutTests/http/tests/loading/css-no-cache-revalidation.html
[add] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/LayoutTests/http/tests/loading/resources/no-cache-css.php
[add] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/LayoutTests/http/tests/loading/resources/no-cache-xslt.php
[add] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/LayoutTests/http/tests/loading/resources/reference-css-no-cache.xhtml
[modify] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/Source/core/fetch/CSSStyleSheetResource.cpp
[modify] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/Source/core/fetch/XSLStyleSheetResource.cpp

This affects our large cloud system greatly (thousands of users), is there some way to know when a fix will be pushed out so we can tell our customers?

We don't comment on release dates, but as you can see above we merged the fix to the m53 branch.

Hi @Chrome Team,

We are waiting for the fix and this is not still available in the Stable 53 release. Can you please help us? 

As all the users, I have verified the fix on latest Chrome canary on Windows 7,10, Mac 10.11.6 and Linux using Chrome Version 55.0.2873.0.

Thank you very much Prudhvi.

Verified the bug on Windows(7,10), Mac(10.11.6) and Linux(14.04Lts) on Chrome version 54.0.2840.41.

Any idea when the release will be available to users?. Becasue of this we are having hard time in using chrome and started using other browser which is not a good sign.

Please can we have an update on when this will be released?  It is affecting all the users in my workplace and our primary web application.

Our hope is to have a new version deployed by this time next week.  Note that this may change if we encounter issues.  We understand the impact and are working to address ASAP.

Can anyone comment if they are struggling with this issue on Android?  Or are most having problems with desktop (e.g. Windows, Mac, Linux) OSes?

I don't know why you still wish to diagnose the issue when I've tested it in Canary and it's already fixed.. But I imagine most of us are using desktop browsers that are encountering the issue. That being said...

I just tried it on Android using the same version 53 of Chrome. After trying a couple times to reproduce it I was unable to get the stylesheets to "unload"/"get lost", or whatever is happening to them.

I then tried to reproduce it in Chrome on Desktop again, using the same exact steps and successfully "unloaded" the stylesheets in underlying tabs/windows.

Windows 10, but I know it is effecting Mac users as well. I have no information about their current OSX version or Chrome version, but I'd be willing to put a lot of money on the fact it's Chrome Stable v53, the same as the rest of us, since that's when Chrome developers released the kracken on our ships to begin with.

Thanks for the update amineer.

I can confirm we are using a mix of 32-bit/64-bit Chrome 53 on Windows 7.

#71 - I do not think the Android question was about diagnosis, but about user impact - if most of the software that encounters this bug is mostly desktop software, the patch might only be released to desktop and leave Android alone.

While this issue is fixed in the canary, keep in mind that it might have broken something else, which is why a stable patch is taking a lot of time (it needs a lot of testing, since a billion of people or so will be getting it and you would not want them to miss an issue like this one, right? :)).

#73 - that is certainly one way to look at it..

It took days for them to acknowledge this issue. Once acknowledged, it took them all of an hour to fix it. Should this then take 2 weeks to "test"?

No, that doesn't make much sense to me. I believe they don't want to bother with a new release just for this issue because they deem it minor (just refresh, right). So they're not only testing this one fix, but all the other features they've added between 53 and 55.

Which goes back to a comment I left on a duplicate bug, this should have been hotfixed off of a stable branch and merged into development branches after the fix was deployed (53.0.2785 > 53.0.2786). It should not have been fixed in a development branch, which is the most likely hold up (53.0.2785 > 55.0.2873).

And besides, if their testing was so rigorous, how did this even get promoted to a stable release?

Of course it is not the only fix (another fix that severely affects jQuery, without refreshing, is also there, for example), but they are definitely not adding every change that was made between 53 and 55. You can see the list of changes that the next stable patch release will be getting. It is not really that long -
https://chromium.googlesource.com/chromium/src/+log/53.0.2785.147
(Disregard version increments, of course and stop at "Incrementing VERSION to 53.0.2785.116").

And yes, it can take two weeks to test. It is being tested on multiple platforms (and versions) and on many websites.

And yes, the testing tries to be as rigorous as possible, but they are still human beings and the resources are limited. And I think you can agree this is an edge case.

Anyway, the issue tracker is not the place for this discussion. Signing off. ;)

phistuck@ nailed it with both of their comments, some minor details aside.  That said, I want to make something clear - it's not acceptable for us to ship regressions like this, and we're performing a post-mortem on the situation to avoid this occurring in the future by looking at things like better automated / manual regression testing, etc.  We really apologize for the inconvenience that this has caused all of our end users.

#76 - good to hear.

As I've reported elsewhere, I confirm that the problem occurs also with Android Chrome v53 and v54 beta, not v52.

lbarbareau@, where else have you reported that?  How frequently are you seeing this on Chrome for Android?  As of right now we have plans to release an updated desktop version but not an updated Android version as I'm seeing very few reports of this on Android vs. Windows / Mac; if you have a website where you can reliably reproduce this on Android I'd love to hear it.

Verified the fix on Windows(7, 10), Mac OSX 10.11.6 and Linux(ubuntu) with Chrome version 53.0.2785.143.

@amineer Here https://bugs.chromium.org/p/chromium/issues/detail?id=645119#c8

For us the same bug also occurs with frameset/frames into our web app but if I test the supplied chromebug.war, with Android Chrome 53.0.2785.124 and 54.0.2840.34 beta, I can see the lost of colors into the iframes when loading alternately each of them.

Chrome 54 beta has been releases with the fix.  Version 54.0.2840.41

Waiting for Chrome 53

Everyone having this issue: Attached new chromeworkaroundproxy.jar which also works for xls issues (source code is included, so you can use this as example for your own apache/iis fix).

Deleted: chromeworkaroundproxy.jar 4.2 KB

chromeworkaroundproxy.jar 4.2 KB Download

I confirm the fix into Android Chrome beta 54.0.2840.42.

I wonder if anyone experiencing these problems uses @font-face?
When we do in sites susceptible to this bug, we also see this older bug: https://bugs.chromium.org/p/chromium/issues/detail?id=582198, sadly it is set to WontFix.

This patch is now pushing out to stable channel in version 53.0.2785.143 for Desktop (Win,Mac & Linux).

Confirming that on my end, this appears to be resolved in Win10 Chrome Desktop 53.0.2785.143. Thank you for escalating this and not making us wait until next week as previously stated.

Confiming issue fixed on Win7 Desktop; Tks a lot!

Thanks for fixing! @all: When you are sure all your customers are upgraded to fixed chrome version you can remove the workaround jar from your system (better for performance).

Just interested: Where can we find the post-mortum / RCA when it is done?

 Issue 650565  has been merged into this issue.

 Issue 649619  has been merged into this issue.

 Issue 651391  has been merged into this issue.

Thx to the team for fixing this (big) bug in about 3 weeks.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/54c7dbb6ffaf423ca61bf7382db7a506b4b759df

commit 54c7dbb6ffaf423ca61bf7382db7a506b4b759df
Author: Kouhei Ueno <kouhei@chromium.org>
Date: Fri Sep 23 00:24:54 2016

{CSS,XSL}StyleSheetResource should mark their clients as finished on checkNotify

Before this CL, {CSS,XSL}StyleSheetResource::checkNotify didn't trigger markClientFinished as Resource::checkNotify did.
This CL aligns {CSS,XSL}StyleSheetResource::checkNotify to trigger it properly.

BUG= 647151 

Review-Url: https://codereview.chromium.org/2353903002
Cr-Commit-Position: refs/heads/master@{#419969}
(cherry picked from commit 3598c8bc9c56409f7c239c377fe6e42786d6aaa0)

Review URL: https://codereview.chromium.org/2362983002 .

Cr-Commit-Position: refs/branch-heads/2840@{#504}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[add] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/LayoutTests/http/tests/loading/css-no-cache-revalidation-expected.txt
[add] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/LayoutTests/http/tests/loading/css-no-cache-revalidation.html
[add] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/LayoutTests/http/tests/loading/resources/no-cache-css.php
[add] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/LayoutTests/http/tests/loading/resources/no-cache-xslt.php
[add] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/LayoutTests/http/tests/loading/resources/reference-css-no-cache.xhtml
[modify] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/Source/core/fetch/CSSStyleSheetResource.cpp
[modify] https://crrev.com/54c7dbb6ffaf423ca61bf7382db7a506b4b759df/third_party/WebKit/Source/core/fetch/XSLStyleSheetResource.cpp