Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 246875 Chrome not rendering webpage CSS and images correctly on page refresh
Starred by 128 users Reported by kumar.ra...@gmail.com, Jun 5 2013 Back to list
Status: Fixed
Owner:
Closed: Aug 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression



Sign in to add a comment
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.94 Safari/537.36

Example URL:
http://portal.utpa.edu/utpa_main/daa_home/cosm_home

Steps to reproduce the problem:
1. Load webpage. Everything renders ok.
2. Press F5 or refresh the page or click on a navigation link on page. CSS is broken and page display breaks.
3. Hard refresh page and page displays correctly again.

What is the expected behavior?

What went wrong?
CSS does not render correctly. CSS images are not getting rendered. Web server log has a lot of 304 errors to assets. Only Chrome issue works fine on all other browsers and platforms.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes Till 3 weeks ago or before last update to Chrome.

Does this work in other browsers? Yes 27.0.1453.94 m on windows and mac

Chrome version: 27.0.1453.94  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)

Please fix asap.
 
Cc: msrchandra@chromium.org
Labels: -Cr-Content -Pri-2 -Type-Bug -OS-Windows Cr-Blink-Rendering Pri-1 Type-Bug-Regression OS-All M-26
Status: Untriaged
Able to reproduce this issue. Providing the Bisect info,

Chrome Good Build -- 26.0.1406.0 (Official Build 181233) m
Chrome Bad Build  -- 26.0.1407.0 (Official Build 181436) m
You are probably looking for a change made after 181314 (known good), but no lat
er than 181333 (first known bad).
CHANGELOG URL:
  http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/tru
nk/src&range=181314%3A181333
Comment 2 by and...@bibik.ca, Jun 22 2013
Here is whole thread about this issue from people experiencing it with some hints on why it happens.
http://productforums.google.com/forum/#!topic/chrome/zID6uQQfKH8

Thanks. We have read those threads and are aware of the 304 response sent by web server. Unfortunately we cannot fix it that easily. Since all other browsers including chrome have been supporting this for years is this something that chrome can fix so it can fallback gracefully instead of a bunch of broken websites? 
Comment 4 by noelwe...@gmail.com, Jun 25 2013
I've had the same refresh problems... only with Chrome on Macs. Chrome for Windows is fine.  All other web browsers are fine across all platforms.
So Google, is there any action plan from your behalf regarding this anoying behaviour?
Comment 6 by Deleted ...@, Jun 27 2013
are there some clear instructions on how to setup a server to avoid this behaviour?
Comment 7 by Deleted ...@, Jul 4 2013
Do I get payed if I fix it? :D
Comment 8 Deleted
We are using a temporary workaround. All of our sites reference a common js file and we have added the below code to it so that the CSS files are requested on each call to the server and only when using chrome. 
Yeah it is an issue where the server shouldn't return a 304 code but we are using an application from Oracle and it is not easy to get such behavior changed. Chrome unfortunately is not built around understanding what enterprise customers need and sadly is turning out to be another crap that we have to do hacks to support.

$(document).ready(function(){
            var UA = navigator.userAgent.toLowerCase();
            if(UA.indexOf("chrome") >=0 && UA.indexOf("Mobile") < 0 && UA.indexOf("Android") < 0){ 
                var links = $(document.head).find("link");
                $.each(links, function(indx, elm){
                    var href = $(elm).attr("href");

                    if (href.toLowerCase().indexOf("portal") >=0){
                        $(elm).attr("href", href + "?v=" + Date.now());
                    }
                });
            }
Cc: japhet@chromium.org jam...@chromium.org abarth@chromium.org
Owner: mkwst@chromium.org
Hmm, so it seems many web servers are serving up 304 HTTP responses with actual contents that we're expected to serve.  This appears to be a regression from http://trac.webkit.org/changeset/142068.  Mike?

(mostly) related nit about the workaround code:

>            var UA = navigator.userAgent.toLowerCase();
>            if(UA.indexOf("chrome") >=0 && UA.indexOf("Mobile") < 0 && UA.indexOf("Android") < 0){ 

won't the checks for 'Mobile' and 'Android' always fail since UA is lowercase?
Cc: tkent@chromium.org morrita@chromium.org
 Issue 70237  has been merged into this issue.
Labels: -M-26 M-30
Status: Available
Status: Assigned
Maybe this CL is relevant: http://trac.webkit.org/changeset/142068 ("Entity-header extension headers honored on 304 responses")

mkwst@: can you take a look? I am assuming that we reject a certain class of malformed 304 which causes this issue. There are apparently a lot of servers that send gibberish such as Content-Type:text/plain in their 304 for CSS resources, can't we just handle the 304 and ignore the rest?

Thanks.
> Hmm, so it seems many web servers are serving up 304 HTTP responses with actual contents that we're expected to serve

I would actually read it differently: Many web servers are serving up 304 HTTP responses with actual content that you are *NOT* expected to serve (but which is generated by the server somewhere along the line anyway, such as a default Content-type and stuff)

I therefor agree with Ken: Handle the 304, and ignore the rest. Read this as "304 means that everything you know is good; everything else you get in this response can be ignored"
Further information: The spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5) says that the response SHOULD NOT include other entity headers (or even MUST NOT under some circumstances). It should be possible to argue that the presence of such headers is therefore normally a server bug, and that they can be ignored.

"If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers."

@jamesr..Thanks for the nit on the code ...the developer has updated it.
Hello Google,

Can you please fix this issue by ignoring contents with 304? To our client, Chrome is  not working while other browsers are.
Comment 18 by Deleted ...@, Aug 1 2013
If you want to seamlessly reload css onto a page, but only for chrome then implement the following on your page:

function reloadStylesheets() {
    var queryString = '?reload=' + new Date().getTime();
    $('link[rel="stylesheet"]').each(function () {
        this.href = this.href.replace(/\?.*|$/, queryString);
    });
}


$.browser.chrome = /chrom(e|ium)/.test(navigator.userAgent.toLowerCase()); 

if($.browser.chrome){
reloadStylesheets() ;
}
Comment 19 by Deleted ...@, Aug 26 2013
I also had this issue. But the issue is resolved now.
To resolve this issue it is must to use attribute  type="text/css" in link tag.And
try to avoid loading the css at runtime.
for example:
<link rel="stylesheet" type="text/css" href="/Style/Style.css"/>
Comment 20 by Deleted ...@, Aug 27 2013
I solved the problem for my website by replacing @import(external.css) in my main stylesheet with the content of the file.
Unluckily, I don't have any such @imports in any of my style-sheets and
still it doesn't work.
This is breaking our portal in Google Chrome. Please fix!
neither of the 2 fixes suggested worked :(... I guess someone is already assigned this issue, so hopefully it'll be looked after very soon. (Hope so his/her issue list is not long and this one gets some priority)
http://portal.utpa.edu/utpa_main/daa_home/cosm_home has fixed the server-side and doesn't replicate anymore. I mistakenly took that to mean that the issue was fixed in more recent versions of Chrome.

https://learndev.unm.edu/ exhibits this problem, however. I'll put up a fix shortly and request a merge back to Beta.
Project Member Comment 25 by bugdroid1@chromium.org, Sep 6 2013
The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=157358

------------------------------------------------------------------------
r157358 | mkwst@chromium.org | 2013-09-06T08:42:37.696622Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/cache/resources/stylesheet304-bad-content-type.php?r1=157358&r2=157357&pathrev=157358
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/cache/content-type-ignored-during-revalidation-expected.txt?r1=157358&r2=157357&pathrev=157358
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/fetch/Resource.cpp?r1=157358&r2=157357&pathrev=157358
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/cache/content-type-ignored-during-revalidation.html?r1=157358&r2=157357&pathrev=157358

Revalidation header blacklisting should be case-insensitive.

Headers like 'content-type' should be ignored for 304 responses, even if
they are delivered as 'Content-Type', or 'CoNtEnT-TyPe', etc.

BUG= 246875 

Review URL: https://chromiumcodereview.appspot.com/23591029
------------------------------------------------------------------------
Comment 26 by mkwst@chromium.org, Sep 18 2013
Labels: Merge-Requested
Hello, lovely release managers. This patch has been in for a week or so, and seems to resolve the problem without additional regressions.

The patch itself is two very simple changes to ensure that a check is case-insensitive. I'd like to merge it as far back as you'll let me. :)

WDYT?
Comment 27 by mkwst@chromium.org, Sep 18 2013
Cc: kerz@chromium.org karen@chromium.org
Comment 28 by kareng@google.com, Sep 18 2013
my instinct is to make this wait for m31. it's so late in m30 now. can u ping me on safety of this?
Comment 29 by kareng@google.com, Sep 23 2013
Labels: -Merge-Requested Merge-Approved
Project Member Comment 30 by bugdroid1@chromium.org, Sep 23 2013
Labels: -Merge-Approved merge-merged-1599
The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=158195

------------------------------------------------------------------------
r158195 | japhet@chromium.org | 2013-09-23T18:06:16.556147Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/branches/chromium/1599/LayoutTests/http/tests/cache/resources/stylesheet304-bad-content-type.php?r1=158195&r2=158194&pathrev=158195
   A http://src.chromium.org/viewvc/blink/branches/chromium/1599/LayoutTests/http/tests/cache/content-type-ignored-during-revalidation-expected.txt?r1=158195&r2=158194&pathrev=158195
   M http://src.chromium.org/viewvc/blink/branches/chromium/1599/Source/core/loader/cache/Resource.cpp?r1=158195&r2=158194&pathrev=158195
   A http://src.chromium.org/viewvc/blink/branches/chromium/1599/LayoutTests/http/tests/cache/content-type-ignored-during-revalidation.html?r1=158195&r2=158194&pathrev=158195

Merge 157358 "Revalidation header blacklisting should be case-insensitive."

Headers like 'content-type' should be ignored for 304 responses, even if
they are delivered as 'Content-Type', or 'CoNtEnT-TyPe', etc.

BUG= 246875 
TBR=mkwst

Review URL: https://codereview.chromium.org/24380002
------------------------------------------------------------------------
Comment 31 by Deleted ...@, Oct 8 2013
Hi folks,
i had some similar issues which could be tracked down to the application which chrome was using. due to some misconfig it replied text/html or application/json header for css files, that confused chrome a lot, and especially if having cached the responses already. FF did even worse, but once fixed in that app chrome is behaving well.
Hi,  I this issue today in Chrome Version 30.0.1599.101 m on Windows. The original style is NOT removed but subsequent refreshes of the page get the 304 response. The issue is manifested by a jquery call to get the css value for border-width-top, which returns 1px on first load and 0px for all subsequent loads - even though we can see the border in the browser and if we add a timeout of 1 sec then retest that css value it has returned to 1px. This will be a live issue for anyone using jquery plugins that are sensitive to css measurements at load. Please fix.
Comment 33 Deleted
Still experiencing this issue on: Version 31.0.1650.57 m

The issue is clearly noticeable via this Twitter Bootstrap 3.0.2 example: http://getbootstrap.com/examples/jumbotron/

1) Click the link, and note the minor space between the input fields in the nav bar.
2) Hit F5
3) Note that the CSS was not rendered correctly and the margin/padding between the input fields is gone.


Comment 35 Deleted
Several Wordpress users are now experiencing this issue after updating to the most record Wordpress build:

http://wordpress.org/support/topic/wp-doesnt-display-content-text-on-chrome?replies=16#post-5283430
Not sure if it's the same bug that I faced today or not. 

In my case Blink renders page wrong most of the times on first load and sometimes on refresh. On locally hosted page refresh/hard_refresh usually makes it display things like it should, but when I hosted it remoteley it failed most of the times on refresh too. It looks like it depends on what will get loaded faster — external stylesheets, or HTML content. And when page wins it breaks the style rules.

You can find test case in attachment. It represents two rendering issues caused by this bug:
- styles doesn't get applied to the scrollbar, at least untill it will be hidden and shown again
- One of two floating blocks wraps to the new line in some cases (when it shouldn't)

http://i.imgur.com/2kj0B37.png - wrong
http://i.imgur.com/cjKGYXX.png - correct

Few more words about floating elements. For both of them 'display' property was set to 'block' and 'float' to 'left'. If both are <a> tags or <div> tags then nothing gets wrapped, even if scrollbar stays unstyled. But when first element is inline by default (<a>) and second one is a block element (<div>) - then second one gets wrapped.

I successfully repeated/reproduced this in Chrome 34 (stable) running on WinXP x86 and Chrome 36 (dev-m) on Win7 x64. Chromium based Opera also affected, but I wasn't able to make it work wrong in chromium based Yandex Browser, however I tested it with only locally hosted test case. Firefox, IE8 and old Opera (Presto) rendering floating blocks from header properly all the time.
testcase.zip
1.6 KB Download
Comment 38 by Deleted ...@, May 12 2014
Broken CSS in Chrome still on most if not all of my back end pages.  I will not recode my sites just for Chrome.  I will stop using Chrome completely however.  Adios.
Comment 39 Deleted
Comment 40 Deleted
Comment 41 by tkent@chromium.org, Jun 10 2014
Cc: -tkent@chromium.org
Comment 42 Deleted
Comment 43 by Deleted ...@, Jun 10 2014
I just added an SSL to my site. I see the text but no CSS or images are there. It is on a dedicated server and I have a full control of the code.

All paths currently are relative. I can view images and css when I go to those files directly whether using HTTP or HTTPS. But when i load a page they are not loading...

When I use Firebug and look in NET, I see for each image 302 Found. What does that mean?

What changes do I need to make to make sure http and https display site similarly?
Comment 44 by dpbea...@gmail.com, Jul 30 2014
I'm having this issue as well. The first time my pages load, everything is fine, but if the page is refreshed, my header moves down in the middle of the page past text, etc. This is only an issue in Chrome as far as I can tell.
Comment 45 by Deleted ...@, Aug 7 2014
I also got same issue. Chrome developers fix the issue or tell some alternative solution
Comment 46 by Deleted ...@, Aug 27 2014
This is driving me mad this issue.  The css/images doesn't load properly 75% of the time for various pages eg. 

http://goringeaccountants.co.uk/

I am actually finding myself going back to IE!

For me the problem was related to a Chrome extension. After removing the problematic one, it didn't happen anymore.
Comment 48 by Deleted ...@, Sep 2 2014
I have had this issue as a basic Chrome end user for months. I can't believe this hasn't been fixed yet. I am switching to Firefox. 
Comment 49 Deleted
Comment 50 Deleted
Comment 51 Deleted
Comment 52 Deleted
Comment 53 Deleted
New example: http://erdnussknacker.de. The box at the top right is pushed down and the menu has a small top spacing. Click any navigation link on the site to fix it temporarily. Then reload the site and it is broken again. In Firefox and Opera it is working fine. This needs to be fixed now!
Comment 55 by fbo...@gmail.com, Sep 23 2014
@54 - your site have only one CSS which is loaded every time in chrome. You seem to have some other problem unrelated to this issue.
When accessing your site through https Chrome blocks assets as a security measure because the certificate is self signed. We've had the same issue and solved it by paying a few bucks for a certificate.


Comment 57 Deleted
Labels: -Cr-Blink-Rendering Cr-Blink-Layout
Migrate from Cr-Blink-Rendering to Cr-Blink-Layout
Comment 59 by Deleted ...@, Feb 5 2015
FIXED!

Make sure your CSS is coming from one source for the problematic page/element. I was having inline background styles support by @import css to position the image and a few jquery injected CSS, that caused a stacking problem especially that I had onresize and on scroll on for the window... Bug still but a fix at last
Comment 60 by Deleted ...@, Mar 11 2015
Hi i have the same problem when i hit the refresh button, http://www.coronastar.ro/
on another broswer i don't have this "view bugs"
Comment 61 by fbo...@gmail.com, Mar 11 2015
#60 - your site looks god to me...
Comment 62 Deleted
Comment 63 by Deleted ...@, Mar 11 2015
Just in Chrome appear this bug view..., right click> refresh and please come to a reply:)
Comment 64 by fbo...@gmail.com, Mar 11 2015
I tested your site on latest stable chrome. No combination of refreshing (f5 and ctrl+f5) made the site look bad. I don't think it is this bug that causes problems on your site for you.
Please check Network pane in Developer tools and check what is wrong.

Original bug caused NONE of CSS and/or images to appear. It happened then Chrome received strange 304 with content-type.
Comment 65 by Deleted ...@, Mar 11 2015
I'm very sorry about the quality(free software to record), you got my point
Video1.avi
8.5 MB Download
Comment 66 by fbo...@gmail.com, Mar 11 2015
Watched your video.

From first post:
Steps to reproduce the problem:
1. Load webpage. Everything renders ok.
2. Press F5 or refresh the page or click on a navigation link on page. CSS is broken and page display breaks.
3. Hard refresh page and page displays correctly again.

It looks like CSS on your site is loaded correctly every time...
This bug is about situation where your CSS does not load at all.

Please describe your problem (I do not see any on your video) and how does it relate to this bug report (maybe except title as it is too generic).
Comment 67 by Deleted ...@, Mar 11 2015
So... When I refresh homepage, for a split second appear all images disoriented (CSS) and then return to their design, the whole problem that only happens to homepage on the chrome broswer, I tested with firefox and when I refresh dosen't distroy my hole design for split of second It's smoothly the loading.
v1.png
444 KB View Download
Comment 68 by fbo...@gmail.com, Mar 11 2015
That's how chrome renders pages before css loads. If you feel this is a bug, please create new bug report. Your problem is not related to this bug.
Comment 69 by Deleted ...@, Mar 11 2015
No man I'm not complaining, I just want to solve this rendering to be compatible for chrome
Comment 70 by Deleted ...@, Mar 11 2015
Btw thank you very much for your attention, appreciate!
Cc: cevans@chromium.org
 Issue 249318  has been merged into this issue.
Comment 72 by Deleted ...@, Apr 25 2015
I'm getting the same issue. IE, SAFARI, Firefox are rendering my site properly but chrome is not. 
Capture.JPG
67.2 KB View Download
I am also having the CSS problem.
Comment 74 by e...@chromium.org, Jul 14 2015
Labels: -Cr-Blink-Layout Cr-Blink-CSS
Owner: timloh@chromium.org
Assigning to timloh for triage.
Labels: Hotlist-Interop
What pages are actually breaking for people? None of the linked URLs show any difference for me upon refresh on M43.
One site that is consistently unformatted for me is  www.fidelity.com
Comment 78 Deleted
I tried refreshing www.fidelity.com on multiple platforms (Mac/M44, Mac/M46, CrOS/M44, Linux/M45) and wasn't able to see a problem.
Comment 80 by morrita@google.com, Jul 30 2015
Cc: -morrita@chromium.org
Status: WontFix
I'm going to close this. The issue from the original report has been fixed long ago (comment #25). If people are still seeing similar problems, then feel free to file new bugs for these.
 Issue 347697  has been merged into this issue.
Status: Fixed
Updating status to reflect original issue (#c25)
I will be polite.  BS!  The problem is NOT fixed and there are LOTS of people that not only have the problem but have offered to be testers in order to solve the problem.  Ignoring it does NOT make it go away.
Comment 85 by phistuck@gmail.com, Mar 24 2016
#84 -
So much for being polite.

I went to www.fidelity.com and did not experience any issues. Your problem might be a different one (perhaps a localized issue in your system even). File a new issue (you can add a comment here with the new issue number) and we can try and find your issue. Are you the developer of that website, or just a user? Just curious.
"fidelity" was just an example.  I would say about 75% of the pages that I open need to be reloaded in order to get a correct display.  Also, particularly if there are links, buttons, etc. I have to load the page multiple times.  After the second load the page looks like it is OK but when you try to click on links, particularly buttons, they are not active and you have to load the page again.

I am a web developer and well versed in PHP and JavaScript so if you need to have someone on my end that can help identify the problem I would be glad to help.
Comment 87 by fbo...@gmail.com, Mar 24 2016
>I would say about 75% of the pages that I open need to be reloaded in order to get a correct display.

Isn't this just the opposite of this issue?
Chrome breaks pages (fails to parse CSS etc) on reload then it have cached versions of these files.
Seems to me that the issue is that Chrome displays the text of a page before it either loads, or at least processes the CSS file(s) and/or the JavaScripts.  Reloading the page possibly picks up the CSS/Javascript that we previously loaded asynchronously---or loaded into the cache during the time when the page text is displayed.
Comment 89 by phistuck@gmail.com, Mar 24 2016
#88 - please, file a new issue for your problem. If you can attach screencasts of the problem, it would help as well.
Chrome Version : 53.0.2785.101 m (64-bit)

This issue again occurred, whenever we open a link in new tab using middle click of mouse button OR open Developer tools, the CSS unloads and page is without style. Refreshing the page works fine again.
Comment 91 by fbo...@gmail.com, Sep 13 2016
#90 You do understand that this bug had these symptoms reversed? First load was ok, refresh did not render CSS...
Just like #89 is sugesting, please fill a new issue...
Good day. since I updated chrome to version 53.0.2785.116 m I have this issue again. if I press F5 the page loses css. It happens in 53.0.2785.116m version of chrome only. IE,FF and previous Chrome work fine.
The new issue is probably  bug 647151 . Fix should be merged to stable soon.
Sign in to add a comment