44285 - Can't LINK stylesheets from JS

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Stanton McCandlish]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)
BuildID:    2000062914

I'm not 100% certain that this is a true bug. Filing in browser-General until
we know whether this is a javascript problem, or an HTTP problem or what. 

At any rate, what's happening is my page has a javascript up near the top that
tries to detect your platform, and assign a platform-specific stylesheet.  It
specifies a generic/default/unix version just before the script, and then
overrides this with a javascript for Mac or Win users.  Actually it's not quite that
smart. Basically, if you are using a Mac, you get the Mac one. If you are using any
other platform AND you have javascript enabled, you get the "Windows" version
(so some Unix users will get that one), and if you have no javascript support
(turned on) you get the "unix" version, regardless of platform.  At any rate, Mozilla
is either only loading the unix version (not interpreting the script at all), or  is not
identifying my machine as a Mac.  The script just looks for "mac" substring.  Or, I
suppose it is possible it is IDing the machine correctly, but not following the
cascade properly, and not letting the 2nd .css override the 1st.

If the script is mangled in some way, please let me know.  For that matter, if
anyone knows how to make it smarter and actually assign the Windows .css file
to Windows only, that'd be very cool. (I didn't write the script, I just got it from
somewhere else).


Reproducible: Always
Steps to Reproduce:
1. Just load the test page.


Actual Results:  Browser is using the first-specified, generic stylesheet.

Expected Results:  Should be using the Mac stylesheet.

PS: If you need to look at the stylesheets, and your browser will not let you
load a .css file into a window as a text file (there are some with this problem),
all the stylesheets have symlinks to them with .txt extensions appended.  E.g.
 http://www.eff.org/stylesheets/effstyle-mac.css
also exists as
 http://www.eff.org/stylesheets/effstyle-mac.css.txt

Toodles...

Comment 1

[Zach Lipton [:zach]]

It seems to me that its your JS that's flawed, not Mozilla. You link to the
stylesheet first and then use the javascript to put in another link.

EXAMPLE:

<LINK TO UNIX STYLE SHEET>
<script>
if mac: write <LINK TO MAC STYLE SHEET>
</script>

End result:

<LINK TO UNIX STYLE SHEET>
<LINK TO MAC STYLE SHEET>

I think that the browser is seing the unix link and because it is first, using
that instead of the mac one. Maybe you should include all the platforms in the
javascript because any browser that doesn't support javascript doesn't support
style sheets.

Then again, I could be completely wrong on this.

Comment 2

[qaz2]

Resolving INVALID.  I will post a modified version of the page.  I have added 2 

alerts, which are right after the mac and win stylesheet assignments.  Mozilla 

will pop up the Mac Stylesheet Alert, as it is supposed to.



HOWEVER,

The navigator.platform gives me "MacPPC" on Netscape 4, but "Macintosh" on 

Mozilla.  Is this supposed to be the case?



Note:

To detect if the comp is running Windows, you can search for "Win" just as you 

search for "Mac," I think.

Comment 3

[qaz2]

Attachment: modified test file

Comment 4

[Stanton McCandlish]

[e-mail] 
>Resolving INVALID.  I will post a modified version of the page.  I have added 2 
>alerts, which are right after the mac and win stylesheet assignments.  Mozilla 
>will pop up the Mac Stylesheet Alert, as it is supposed to.

Nifty test, but it *doesn't* make the bug invalid. Here's why.  Regardless what part of
the script is triggered by Mozilla, and what stylesheets it is or isn't actually loading and 
parsing, the styles that are *applied* are those from effstyle-unix.css.  I tested and
verified this by changing .menu and .MENU at bottom of stylesheet to a huge ugly
14pt in effstyle-mac.css, reloaded, saw no change, did the same with effstyle-win.css
(no change), and finally with effstyle-unix.css, and this time the left-side menu font 
turned to 14pt on reload.

This would appear to conclusively demonstrate a rather serious CSS cascading bug.

Probably bears setting up some javascriptless tests that do nothing but load 2+
.css files in <HEAD>, in series, to mark up some simple demo content, to see if it always 
ignores a second or later .css file that overrides the values of the first, or is only doing it 
under particular circumstances.

>The navigator.platform gives me "MacPPC" on Netscape 4, but "Macintosh" on 
>Mozilla.  Is this supposed to be the case?

Dunno. I suspect that how the platform is determined and reported isn't standardized. 
Either string should match "Mac", though, so I personally don't care. :-)

>To detect if the comp is running Windows, you can search for "Win" just as you 
>search for "Mac," I think.

Well, I figured that.  I guess what I was getting at is that I'm too Javascript-stupid to 
actually know how to re-write the script with another loop to do that. I don't know js at 
all, I just got this script from a friend.   Ideally it'd say "If Mac, use effstyle-mac.css. If 
Win, juse effstyle-win.css. If anything else, use effstyle-unix.css. And if no js is enabled, 
use effstyle-unix.css by default", please pardon my incredibly wretched pseudocode.



[e-mail] wrote:
>It seems to me that its your JS that's flawed, not Mozilla. You link to the
>stylesheet first and then use the javascript to put in another link.
[...]
>I think that the browser is seing the unix link and because it is first, using
>that instead of the mac one.

If this is the case, then this is certainly a bug. CSS is called *cascading*
stylesheets for a reason.  :-)   Namely, any stylesheet is overriden by subsquently 
parsed stylesheets or CLASS instances.  This is precisely why the generic .css is loaded
first, such that only systems that trigger the custom .css files will load them, and any
browsers with js turned off will still load at least the generic stylesheet. 'Zilla
doesn't appear to be loading (or at least not properly cascading) either of the custom
variants (despite [e-mail]'s proof that it is parsing the script correctly), just 
sticking with the generic one that it hit first.

>Maybe you should include all the platforms in the javascript because any
> browser that doesn't support javascript doesn't support style sheets.

I don't see why that would necessarily be true, though it might be incidentally
true in current browser deployment.  Doesn't matter anyway - many people turn off
the js support their browser has, but leave CSS enabled (though I find this doesn't
work in NS 4.x Win - if you turn of js, CSS dies too. "Oops".)

Comment 5

[Asa Dotzler [:asa]]

over to style system.

Comment 6

[Marc Attinasi]

The problem is that the secondary stylesheet, the one LINK'd by the script, is 
never getting loaded. In viewer, if you dump the stylesheets, you will see that 
the unix style sheet is loaded by the observing the console-output:
   CSS Style Sheet: http://www.eff.org/stylesheets/effstyle-unix.css 
and then a list of all of the rules in that sheet, however there is no ouptut to 
indicate that CSS Style Sheet: http://www.eff.org/stylesheets/effstyle-win.css 
has loaded (also there is no indication that the load was even attempted).

My guess is that the interaction between the Parser and the scripting engine is 
flawed and that the LINK that the script is writing is not getting processed 
correctly. I will attach a much smaller testcase that will allow us to debug the 
script-execution and subsequent LINK statement more easily.

Comment 7

[Marc Attinasi]

Attachment: Testcase that just LINK's a second stylesheet via script

Comment 8

[Marc Attinasi]

CC'ing Harish since he has dealt with these parser/script/css-loader issues 
before.

Comment 9

[Pierre Saslawsky]

Changed the summary from "Mac 'zilla not appearing as "mac" in platform test 
(js)" to "Can't LINK stylesheets from JS".

Comment 10

[Pierre Saslawsky]

Attachment: better testcase

Comment 11

[Pierre Saslawsky]

Attachment: even better testcase for our Win32 friends

Comment 12

[Pierre Saslawsky]

The stylesheet which is LINKed by script is indeed loaded in 
CSSLoaderImpl::LoadStyleLink() and parsed in CSSLoaderImpl::ParseSheet() but 
obviously, it doesn't end up in the right place because, as Marc noticed, it 
doesn't appear in the document when we do Dump Stylesheets in Viewer.

So I played with document.write() a bit and I found a regression: when a DOCTYPE 
is specified, document.write() doesn't seem to work at all. I built a testcase 
based on htmlparser/tests/html/40143.html. This regression, like another one I 
found today, occured between 06/28 and 06/30. 

Reassigned to Parser/harishd to fix the regression with document.write() and then 
look into the problem with LINKed stylesheets.

Comment 13

[Pierre Saslawsky]

Attachment: testcase that shows both problems: doc.write() + LINK stylesheet

Comment 14

[Pierre Saslawsky]

The problem with the LINKed stylesheet could be a dup of bug 41637. I'm going to 
ask the folks there what they think. We still have the regression with 
document.write()...

Comment 15

[harishd]

Please refer to the patch in bug 44759.

Comment 16

[harishd]

Attachment: Proposed patch.

Comment 17

[Nisheeth Ranjan]

Simple fix.  Marking nsbeta3+.

Comment 18

[harishd]

Fix is in. Marking FIXED.

Comment 19

[ckritzer (gone)]

I've checked this out on:
- LinuxRH62 2000-09-07-08-M18 Commercial
- Win98     2000-09-07-08-M18 Mozilla
- MacOS86   2000-09-07-04-M18 Commercial
And it doesn't seem to be working for any of them....

Reopening.

Comment 20

[harishd]

Okay, the document.write problem is definitely fixed. However, I think, the 
problem with linked style sheet exists. Per Pierre's comment ( 2000-07-19 03:19 
) reassigning this bug to him.

Comment 21

[harishd]

CCing Mark and myself to the bug.

Comment 22

[Pierre Saslawsky]

IMPORTANT: Stanton McCandlish, I'm closing this bug as fixed again but an action 
is required from your side to fix the page at http://www.eff.org/test.

The thing that happens is the following... Since the LINKed stylesheets have a 
TITLE, they become selectable by the user under "View | Use Stylesheet" and the 
first one is selected by default ("EFF Unix/Generic Stylesheet"). In order to 
select the right default stylesheet, you need to add:

document.write('<META HTTP-EQUIV="default-style" CONTENT="EFF Mac Stylesheet">');

before linking the Mac stylesheet with document.write('<LINK REL=
"stylesheet"...). A similar fix should be done for the Win/PC stylesheet, of 
course.

More info about LINKed stylesheet can be found on
http://www.w3.org/TR/REC-html40/present/styles.html#h-14.3.1

Comment 23

[ckritzer (gone)]

Ian, would you mind having a bash at this one?  Thanks dude!

Comment 24

[Hixie (not reading bugmail)]

Attachment: Stylesheet for next test case

Comment 25

[Hixie (not reading bugmail)]

Attachment: Simple and self explanatory testcase. Output should be green, not red.

Comment 26

[Hixie (not reading bugmail)]

VERIFIED FIXED on Windows 2000 Commercial Build 2000091805 and RedHat Linux 6.2 
Commercial Build 2000091806 using simple test case created.

Note that original page provided does not work as expected because of the 
previously mentioned error on the page. (You need to add the 'preferred 
stylesheet' selection or swap the order of the stylesheets.)