297545 - Sometimes CSS that is linked with an @import than then includes more CSS with @import doesn't get used

Status: RESOLVED DUPLICATE of bug 227976

(Core :: CSS Parsing and Computation, defect)

Description

[Chris Croome]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1

I don't know how to duplicate this, but I have have had it happen on several
sites using several different (new) versions of mozilla and firefox and other
people have told me that they have the same problem.

Basically it appears that if a page links to some CSS using @import and then the
imported CSS links to some more CSS using @import them *sometimes* and second
CSS file is not used.

An example of a site that does this is here: http://www.indymedia.org.uk/ in
this case *all* the CSS is in the second file.

Another example is here: http://www.webarchitects.co.uk/ for this site the
layout is in the first CSS file but the colours in another one -- if this page
has no purple bar at the top then this is the bug in action.





Reproducible: Sometimes

Comment 1

[zak]

I've observed this too -- it seems most reproducible when using HTTPS (try
https://www1.indymedia.org.uk/). If it doesn't occur the first time, clicking
shift+reload often provokes it.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I've been completely unable to reproduce this.  I'll need a way to do that
before I can try to do anything about the problem....  I assume this happens
with a clean profile, no extensions?

Comment 3

[alster]

I have encountered the same problem on 
https://publish.indymedia.org.uk/en/static/editorial.html
where related link type style sheet references are used.

This same thing has happened on https://dispatch.indymedia.org.uk/ . 

At least the last web page uses valid XHTML and CSS as reported by
http://validator.w3.org

I was able to reproduce this with a clean profile on a Mozilla suite's web
browser and Galeon (up to date Debian Testing packages). The same thing also
happened using Firefox, however it has several plugins on that profile.

This behaviour was not reproducible with a current version of Konqueror.

To reproduce the problem, it is neccessary to do full reloads of the page in
question for up to ten times. The problem will not occur on every reload.

Comment 4

[Boris Zbarsky [:bzbarsky]]

When you say full reloads, do you mean shift-reload?

Comment 5

[alster]

Exactly, reloading the page via shift-reload and thus recreating the cache.
Restarting the browser & deleting cookies won't make a difference either. It's
still reproducible.

Comment 6

[Boris Zbarsky [:bzbarsky]]

[e-mail], what Gecko version were you using?  I've been completely
unable to reproduce in either current trunk Firefox or current trunk Mozilla
using your steps (I shift-reloaded 30 times in each, and the stylesheet was
there every single time).

Comment 7

[alster]

Just to make sure, we're talking about the SSL'd version of this web page,
right? I just tried to modify the URL given above to make it more obvious, but
access restrictions apply and I must not change it.

Here's the browser versions I came across this with:

Mozilla 1.7.8
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1

Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.8) Gecko/20050517 Firefox/1.0.4
(Debian package 1.0.4-2)

I didn't retry Galeon as it uses the same engine as Mozilla Suite IIRC.

I'll attach a couple of screen shots for these browsers.

I realized that, here locally, it is easier to reproduce this behaviour by
permanently accepting the SSL certificate (in contrary to just temporarily
accepting it) and visiting some other pages which require complex rendering
before. But this is not neccessary to reproduce it, it just seems to make it easier.

Comment 8

[alster]

Attachment: Viewing with shiny new Firefox profile

Comment 9

[alster]

Attachment: Mozilla view 1

Comment 10

[alster]

Attachment: Mozilla view 2

Comment 11

[alster]

Attachment: Mozilla view 3

Comment 12

[alster]

I forgot to note that my last post refers only to https://dispatch.indymedia.org.uk/

While I have seen a similar behaviour with the web site
http://www.indymedia.org.uk/ (but I think it was hosted in another location then
and I was accessing it via SSL) I am not able to reproduce it on this site
*now*. I also can't reporduce this with http://www.webarchitects.co.uk/ now.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Oh, I see.  People are all testing this with 1.7-branch builds.  With those I
_can_ reproduce the problem.  A bit of testing shows that the problem got fixed
between June 16, 2004 and June 17, 2004 on the trunk; given that all the data in
question is sent with "content-encoding: gzip", this is a duplicate of bug 227976.

Please, please test layout bugs with a current-ish trunk build; the Deer Park
alpha is the best choice right now.  The 1.7 branch (Mozilla 1.7.x and Firefox
1.0.x) is using a layout engine from April 2004; a lot of things have been fixed
since then.

*** This bug has been marked as a duplicate of 227976 ***