Closed Bug 315105 Opened 20 years ago Closed 12 years ago

whilst loading a site CSS stylesheets are not applied at all (somtimes just delayed)

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INCOMPLETE

People

(Reporter: e.bretelle, Unassigned)

References

(
URL
)

Details

Attachments

(2 files)

css not applied to a.m.o
57.16 KB, image/png
Details
case 2: css-file applied 'delayed'
49.20 KB, image/png
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.12) Gecko/20050919 Firefox/1.0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.12) Gecko/20050919 Firefox/1.0.7 When loading http://www.info-concours.fr , the style sheet are fetched (as i can see through networking tools such as ethereal) but are not applied to the rendering Reproducible: Always Steps to Reproduce: 1. make sure your cache is cleared 2. go to http://www.info-concours.fr 3. there is no style applied to the page 4. force reloading (Ctrl-F5 on windows) or press reloading button several times 5. finally the stylesheet is applied Actual Results: no style sheet applied Expected Results: mozilla/firefox should have fetch and apply the css files this happen when using firefox on both linux or windows. the same thing happen with mozilla
The page is in standard compliance mode, while the stylesheets are served as text/plain. Either the page needs to become quirks mode or the stylesheets need to be served as text/css.
Thanks for your help Martin. As far as I can see, the css' files are served as text/css. I requested the css files through telnet, the server replies with a "Content-Type: text/css". Checking the response headers with the web devellopers tool bar, i get the same response. The problem is not much of compliance I guess, as when reloading the page, the css get finally applied :S .
When look at the Page info at: http://www.info-concours.fr/css/infoconcours_.css The css-file that gets loaded, I see: text/plain as mime-type.
Since following is DOCTYPE of the site, Gecko applies "Almost Standards Mode" to the page. > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> See http://www.mozilla.org/docs/web-developer/quirks/doctypes.html for "mode"s. Please note that "Page Info." still says "Standrads compliance mode" for both "Standards Mode" and "Almost Standards Mode". Following is HTTP headers by LiveHTTPHeaders. The server apparently returns "text/css" for the CSS files. > --------------------------------------------------------------------- > Host: www.info-concours.fr > GET /favicon.ico HTTP/1.1 > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) > Gecko/20051103 SeaMonkey/1.1a > > HTTP/1.x 200 OK > Content-Type: text/html > ---------------------------------------------------------- > http://www.info-concours.fr/css/infoconcours.css > GET /css/infoconcours.css HTTP/1.1 > Host: www.info-concours.fr > > HTTP/1.x 200 OK > Content-Type: text/css > ---------------------------------------------------------- > http://www.info-concours.fr/css/infoconcours_.css > GET /css/infoconcours_.css HTTP/1.1 > Host: www.info-concours.fr > > HTTP/1.x 200 OK > Content-Type: text/css > ---------------------------------------------------------- > http://www.info-concours.fr/js/default.js > GET /js/default.js HTTP/1.1 > Host: www.info-concours.fr > > HTTP/1.x 200 OK > Content-Type: application/x-javascript > ---------------------------------------------------------- (In reply to comment #3) > When look at the Page info at: > http://www.info-concours.fr/css/infoconcours_.css > The css-file that gets loaded, I see: text/plain as mime-type. Seamonkey 2005110310-trunk/Win-2K says "text/css" in "Page Info." when accessing the CSS file. "text/plain" you got is possibly current Firefox 1.0.x bug because the CSS file is rendered by putting the CSS text between "<head></head><body><pre>" and "</pre></body></html>" internaly. (In reply to comment #0) > the style sheet are fetched (as i can see through networking tools such as > ethereal) but are not applied to the rendering WORKSFORME. Seamonkey 2005110310-trunk/Win-2K seems to display the site as expected when both "Shift+Reload" and "Reload". Result was same on both "Shift+Reload" and "Reload". (Q1) Can you attach screen shot of both "CSS not applied" and "CSS applied"? (Q2) As ar as I remeber, current 1.0.x has some table rendering related issues. Is "Resize window", instead of several times of "Shift+Realod" or "Reload", a workaround? (Q3) Does the problem occur even on Firefox latest trunk nightly?
hi, you can get applied css screenshot from http://www.info-concours.fr/firefox/info-concours-with-css.png and not applied from http://www.info-concours.fr/firefox/info-concours-no-css.png >>>> (Q2) As ar as I remeber, current 1.0.x has some table rendering related issues. Is "Resize window", instead of several times of "Shift+Realod" or "Reload", Nope, resizing the window doesn't make any changes :s
(In reply to comment #5) > and not applied from > http://www.info-concours.fr/firefox/info-concours-no-css.png Not "background: url" only issue, nor "@import" issue(Bug 183348, Bug 290018)... (Q5) Do you enable "pipelining"? Dial-up or ADSL or Fiber channel access? When pipelining and many <img>'s, and when some of images are not got within expected time, the images become broken, or only half of the image is rendered sometimes. This happens even if HTTP GET itself is successuful, and depends on server. This is resolved by consecutive "Reload", because number of already cached images increases on each additional "Reload". If this is also applicable to "css" file, "No CSS applied" would occur. (Note: I use ADSL of spec of max 70Mbps, and I can't recreate your problem) ( although I enable pipelining with newest Seamonkey trunk nightly. )
chantra, do you use "Proxy Server"? We are experiencing odd problem. ( If you can understand Japanese, read http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4728 ) - If a proxy server passes data with "Content-Encoding:deflate", the data sent with "deflate" is truncated. (Both in cache and in real display. No relation to Mime-Type.) Note: This issue isn't reported to b.m.o yet, because we are still uncertain. We've found that a workaround for our issue is setting "Null" to network.http.accept-encoding. (change gzip,deflate to null) chantra, if you use proxy server for HTTP access, try setting network.http.accept-encoding = Null. Can it be a workaround?
> chantra, do you use "Proxy Server"? nope. >If you can understand Japanese, neither sorry, if I can't help.
i have to confirm this issue still happening the last weeks using the ff3 trunk nightlies. - no proxy - pipelining disabled - connection to inet using dial up (ISDN) affected sites: e.g. b.m.o & a.m.o LiveHHTPHeaders gives me for a.m.o.: -------------------------------------------------------- https://addons.mozilla.org/css/rustico.css GET /css/rustico.css HTTP/1.1 Host: addons.mozilla.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030405 Firefox/3.0.0.0 Accept: text/css,*/*;q=0.1 Accept-Language: de-de,en-us;q=0.8,de;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1252,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: https://addons.mozilla.org/en-US/firefox/addons/versions/5817 If-Modified-Since: Thu, 06 Dec 2007 22:50:53 GMT If-None-Match: "55f9-f64f0d40" Cache-Control: max-age=0" -------------------------------------------------------- in this case the css-file wasn't applied at all. i had to delete the cache and make a forced reload to get the proper rendering.
Status: UNCONFIRMED → NEW
Component: General → Networking
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → networking
Version: unspecified → Trunk
sometimes the css-file is just been applied 'delayed', so the site is been rendered correctly after site loading finished. e.g.: screenshot with loading a bug in b.m.o. both a.m.o. & b.m.o. are HTTPs sites but the bug is not limited to HTTPs. since i never saw such behavior in FF2 or other browsers i exclude my relative small bandwidth as source for the bug.
Summary: css stylesheet are not applied, need to force reloading several times before it is taken into account → whilst loading a site CSS stylesheets are not applied at all (somtimes just delayed)
In my case: I use the latest firefox stable release. The styles are not applied if: It's not the 1st time the page is read (in the last 24h) The .css file is not requested (the cached one is "used" instead). The style is available and is applied while the page is loading. When the page finishes loading the styles stop being applied. If I go to view -> Page Style I may reactivate the correct style for the page. If the if-modified-since header is sent and the cached .css is used this bug does not happen. Same happens when the .css file is downloaded.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0 I can recreate a similar problem on at least one website: http://forum.xda-developers.com/ The site loads correctly the first time after starting FF, but may or may not display it correctly a second time. The error occurs at random after some page views. Clearing the cache solves the problem. Reproducible: Random Steps to Reproduce: 1. Start firefox 2. Load up http://forum.xda-developers.com/ 3. The page is displayed correctly 4. UNCLEAR: Maybe browsing other pages is necessary, maybe it depends on the time FF has been running 5. Reload http://forum.xda-developers.com/ or just load another page from this domain 6. The page is not displayed correctly, aka the stylesheet is not applied Actual Results: no style sheet applied in consecutive page view Expected Results: style sheet applied and page rendered correctly Temporary Solutions: Restarting FF or clearing the cache solves the problem temporarily
Filed seperate bug for this, as at least the URL is different. https://bugzilla.mozilla.org/show_bug.cgi?id=812882
(In reply to a351977 from comment #14) > 5. Reload http://forum.xda-developers.com/ or just load another page from > this domain Don't forget that you may not use F5 to reload. The objective is to visit that page while the stylesheet is still in the cache. > Temporary Solutions: > Restarting FF or clearing the cache solves the problem temporarily No need. Reloading using F5 or manually applying it in the view->page style menu will temp solve.
anyone have a testcase that reproduces using current trunk? https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ (except a351977's URL covered inn seperate bug)
URL: http://www.info-concours.fr → NA http://www.info-concours.fr
Flags: needinfo?
Whiteboard: [closeme 2013-01-18]
Resolved per whiteboard
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: needinfo?
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2013-01-18]
(In reply to Phoenix from comment #18) > Resolved per whiteboard What does that mean?
(In reply to brunoaiss from comment #19) > (In reply to Phoenix from comment #18) > > Resolved per whiteboard > What does that mean? That mean that for this bug was set closing date, if nobody steps in with fresh data on actual Firefox versions as Wayne requested in Comment 17. You still see this problem? If yes, try version from Comment 17 link
ok
xtc, do you still see this problem? (brunoais no longer does. And Chantra's address bounces)
Flags: needinfo?(xtc4uall)
(In reply to Wayne Mery (:wsmwk) from comment #22) Nope.
Status: RESOLVED → VERIFIED
Flags: needinfo?(xtc4uall)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: