Linked css files ignored when the href is a call to a script

VERIFIED FIXED in mozilla1.0



Networking: Cookies
16 years ago
16 years ago


(Reporter: Shawn Neumann, Assigned: Stephen P. Morse)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [need info])



16 years ago
Using W2K on Build 2002032603

This is a regression - works in 0.9.9 not in nightlies.

Case:  Create a css link in the header of an HTML page.  Rather than directly
referencing the css file, reference it through a cgi that outputs the
content-type and then the file contents:

<link rel="stylesheet" href="" type="text/css">

Expected Result:  The style sheet would load as if it were accessing the file

Actual Result: In this case, the style sheet fails to load.  It works in 0.9.9,
as well as other browsers (IE 6.0)

I don't have a publically accessable test case that reproduces this.  I tried to
create a small test case, however it worked.  I have not yet been able to
discern what the difference is.  Since the same script call works in 0.9.9 and
not in a nightly it leads me to believ there is some regression here.
0.9.*9*?  Are you sure?

What's the MIME type that the server is sending for the stylesheet?  If it's not
text/css, and we're in standards mode (see ), we'll ignore it.

Comment 2

16 years ago
I just tried doing this, and it works for me (same build as reporter -
2002032603 win2k)

Are you sure that the script is returning the right content type for the CSS
file?  Unless the document is rendered using "quirks" mode, mozilla will ignore
CSS that's not served with a text/css content type from the server.  However,
that applies to 0.9.9 as well (not 0.9.8), so maybe that's not it.

A working testcase that's available to everyone would really help here.

[just mid-aired with David's comment, but am posting anyway 'cause i actually
tried it and it WFM...]

Comment 3

16 years ago
Yes, I have tested the content header.  It is text/css.  With no change in the
environment, it will work on 0.9.9 and not on a the nightly I described.  I will
try to get a publically working test case going and post it.

Comment 4

16 years ago
Ok, I have a test case.  I have not yet been able to determine which aspect of
passing the css file through a script is causing the problem, however the issue
will be quite evident with this URL:

username: test
password: 654321

If you go here in 0.9.9 the css will load and display the page appropriately. 
If you then go in a nightly (I tried it in one from the weekend just now), the
css will not load and the page display will reflect that.  I will try to get a
non-password protected test case, but for now this will do.

Comment 5

16 years ago
Actually, here's a URL with the username and password embeded...

This will be easier to use.
This sounds like a cookie problem to me.  If cookies don't get set correctly,
the script serving up the sheet will serve up a login page instead of the

Comment 7

16 years ago
You are correct, the server will system will serve a login if there is no
authentication cookie present, however in this case you can access the css file
directly by looking at the source and copying the linked location to the
browser.  It will not display a login but rather that actuall css file.  

In addition to this, it will work if you try in 0.9.9 but not in recent (0.9.9+)
OK, now I have a current mozilla again.   This is a cookies bug.  The cookie
_is_ set.  It's not sent to the site, however!

More details:
1)  Set mozilla to allow cookies from "originating server" only
2)  Load the site
3)  Observe that a cookie is _not_ set (cookie manager does not show it).
4)  Allow all cookies
5)  Load the site
6)  Watch the sheet get loaded.
Assignee: dbaron → morse
Severity: normal → major
Component: Style System → Cookies
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: ian → tever
Hardware: PC → All

Comment 9

16 years ago
Although the symptoms are different, the patch just posted to bug 137079 will 
probably fix this bug as well.  Can someone who can reproduce this bug please 
apply that patch and see if it takes care of this problem.
Keywords: mozilla1.0, nsbeta1
Target Milestone: --- → mozilla1.0
Yes, that patch fixes this bug.
Depends on: 137079

Comment 11

16 years ago
Nav triage team needs info: Does this happen on any top sites? What is the
impact on target users?
Whiteboard: [need info]

Comment 12

16 years ago
The impact of this one instance is small.  But see the discussion in bug 137079.  
Although the symptoms there are different, the fix for that bug will fix many 
other bugs as well, this probably being one of them.
This is essentially a duplicate of bug 137079, which is nsbeta1+...


16 years ago
Keywords: mozilla1.0, nsbeta1

Comment 14

16 years ago
Being marked fixed since the patch for 137079 is checked in on trunk.  However 
it is not yet fixed on the branch.
Last Resolved: 16 years ago
Resolution: --- → FIXED


16 years ago
Keywords: fixed1.0.0

Comment 15

16 years ago
verified branch - 05/28/02 linux rh6, mac osX, winNT4
Keywords: verified1.0.0
You need to log in before you can comment on or make changes to this bug.