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

Status: VERIFIED FIXED

(Core :: Networking: Cookies, defect)

Description

[Shawn Neumann]

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="test.pl?file=/style.css" type="text/css">

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

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.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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
http://mozilla.org/docs/web-developer/quirks/ ), we'll ignore it.

Comment 2

[Michael Lefevre]

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

[Shawn Neumann]

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

[Shawn Neumann]

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:

http://newsite.lccbc.org/cgi/new_core.pl?action=d7_browser_load

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

[Shawn Neumann]

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

http://newsite.lccbc.org/cgi/new_core.pl?action=d7_browser_load&CHG=1&username=test&password=654321

This will be easier to use.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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
sheet...  

Comment 7

[Shawn Neumann]

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+)
nightlies.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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.

Comment 9

[Stephen P. Morse]

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Yes, that patch fixes this bug.

Comment 11

[Peter Trudelle]

Nav triage team needs info: Does this happen on any top sites? What is the
impact on target users?

Comment 12

[Stephen P. Morse]

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.

Comment 13

[Boris Zbarsky [:bzbarsky]]

This is essentially a duplicate of bug 137079, which is nsbeta1+...

Comment 14

[Stephen P. Morse]

Being marked fixed since the patch for 137079 is checked in on trunk.  However 
it is not yet fixed on the branch.

Comment 15

[Tom Everingham]

verified branch - 05/28/02 linux rh6, mac osX, winNT4