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.
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.
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...]
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.
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.
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.
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...
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.
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
Status: UNCONFIRMED → NEW
Component: Style System → Cookies
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: ian → tever
Hardware: PC → All
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.
Status: NEW → ASSIGNED
Keywords: mozilla1.0, nsbeta1
Target Milestone: --- → mozilla1.0
Yes, that patch fixes this bug.
Depends on: 137079
Nav triage team needs info: Does this happen on any top sites? What is the impact on target users?
Whiteboard: [need info]
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+...
Being marked fixed since the patch for 137079 is checked in on trunk. However it is not yet fixed on the branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
verified branch - 05/28/02 linux rh6, mac osX, winNT4
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.