Closed Bug 178407 Opened 22 years ago Closed 22 years ago

Changed Stylesheets override style object

Categories

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

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.3alpha

People

(Reporter: m.proctor, Assigned: bzbarsky)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files, 5 obsolete files)

self-contained testcase
(deleted), text/html
Details
assertion that fires, demonstrating the problem
(deleted), patch
Details | Diff | Splinter Review
Actions: Load and apply the stylesheet Change the style object Change the stylehsheet - by updating the LINK element's href Actual Results: ie - style object property changes are preserved moz - stle object properties are overriden by the new stylesheet Desired Results: Shouldn't the style object properties always be visible over a stylesheet I have included an example below, with two small css files. -------testCSs.html--------------------------------------------- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <LINK REL=STYLESHEET TYPE="text/css" HREF="oldStyle.css"> <script type="text/javascript"> //Node appendChild(in Node newChild) var link; var head; onload = function(){ d1 = document.createElement('DIV'); d1.style.position = "absolute"; d1.style.left = "100px"; d1.style.top = "100px"; d1.style.width = "400px"; d1.style.height = "100px"; d1.className = 'madness'; d1.style.backgroundColor = 'yellow'; d1.s = true; d1.innerHTML = 'as this has been set to bgcol = yellow the style sheet is not altering it even though the class is applied after the bg col has been set. This could be bad news'; document.body.appendChild(d1); if (!document.all) { link = document.styleSheets[0].ownerNode; } else { link = document.styleSheets[0].owningElement } head = document.getElementsByTagName('HEAD').item(0); d1.onclick = function() { if (d1.s) { d1.s = false; f1(); } else { d1.s = true; f2(); } } } f1 = function(){ document.getElementsByTagName('LINK').item(0).href="newStyle.css"; //link.href="newStyle.css"; } f2 = function(){ //document.getElementsByTagName('LINK').item(0).href="oldStyle.css"; link.href="oldStyle.css"; } </script> </head> <body> </body> </html> -------oldStyle.css--------------------------------------------- .madness { color:red; background-color:blue; font-family: arial; border-style:dashed; border-color:black} -------newStyle.css--------------------------------------------- .madness { color:blue; background-color:red; font-family:times; border-style:solid; border-color:black}
Attached file oldStyle.css (obsolete) (deleted) —
There should really be an option to attach stuff when reporting a bug.
Attached file newStyle.css (obsolete) (deleted) —
Attached file HTML source (obsolete) (deleted) —
Alright... now we can check the claim.
Attached file Some error corrected. (obsolete) (deleted) —
Attachment #105179 - Attachment is obsolete: true
Dunno if this is really correct. One should have to use document.getElementsByTagName("link").item(0).disabled = true; or something similar _after_ loading both sheets.
but then you would have to pre-load all the stylesheets, whether they are needed or not. If you have dozens of stylesheets for the page, you don't want to pre-load them all if the chances are they will only use 1 or two of the stylesheets in that session.
I am still not sure I understand this bug. Clicking the yellow div results in a red background, a solid border and blue serif text. Clicking again results in a blue background, a dashed border and a red sans-serif text. Etcetera ad infinitum. The clickable text suggests this is what you would want, but the text in this bug report says you would not.
first up ignore the text in the box - that was put in by my collegue, it isn't a clear definition of the problem, sorry I should have updated that as its confusing. To properly understand this you need to look at it in IE too. The DIV is set yellow by changing the style object, it is defined as "blue" in the stylesheet. Correctly the backgroundColor style object change to yellow overrides the blue. However if you then change the style sheet, the stylesheet overrides the style object changing it to red - surely the style object should always override any stylesheet settings, as it does in ie, and it should remain yellow.
Attached file updated the DIV's text to be more relevant (obsolete) (deleted) —
updated the DIV's text to be more relevant
I've been doing a bit of digging. The link: http://www.mozilla.org/docs/dom/domref/dom_style_ref.html#1000986 Doesn't seem to say anything other than to beware that changing the style object property will overwrite a previous definition - it doesn't mention anything about precedent or cascading. Likewise the w3 pages don't talk about precedence or cascading at these links http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-ElementCSSInlineStyle http://www.w3.org/TR/1998/REC-html40-19980424/present/styles.html#h-14.2.2 However the following link about inertRule hints at the rule being inserted into the cascade http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-CSSStyleSheet What is the cascade order? I can't find a definition - is it: link->stylesheet->styleobject So we can either assume that nothing is specified about precedence and cascade and that what is applied, whether it is via the stylesheet of the styleobject, becomes the current definition and thus visible - which is what mozilla does. Or we can assume that a cascade precedence system is in operation and that the styleobject has precedence over the stylesheet - as it does in ie. Without further digging to produce more evidence I don't think you can assume which is correct - according to W3- ie or moz. Hopefully a CSS expert can sort this out, as I'm way out of my depth here.
okay I've found it http://www.w3.org/TR/REC-CSS1#cascading-order - quoted below 5. Sort by order specified: if two rules have the same weight, the latter specified wins. Rules in imported style sheets are considered to be before any rules in the style sheet itself. <STYLE TYPE="text/css"> #x97z { color: blue } </STYLE> <P ID=x97z STYLE="color: red"> In the above example, the color of the 'P' element would be red. Although the specificity is the same for both declarations, the declaration in the 'STYLE' attribute will override the one in the 'STYLE' element because of cascading rule number 5.
So is this INVALID? or WORKSFORME? The last testcase attached seems to do what you want on a recent Mozilla build (it stays yellow when I click it).
This is worksforme (linux trunk build 2002-11-01-21). Mark, please reopen if you're seeing the problem in a recent build (and ALWAYS list your build id in bug reports!).
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
I was using build 1.01 - alpha was being too tempormental for me. I have just installed the latest nightly build. The issue still seems to be the same, the stylesheets take a while to load as they are sourced from the attachment - but when clicking after a few seconds it difinitely still goes red for me. I'm not sayin that is wrong, I'm just saying there is a difference between ie and moz - I don't know which one is correct, but my last comments pasted from W3 indicates that ie has this one right. You can contact me on ICQ 8106598 if you need any quick correspondance.
sorry I meant I was using Moz1.1 - anyway I'm now using the latest nightly build.
OK. Reopening. If I wait a bit, I do see the problem.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
To style system; I see this with a current linux trunk as well. At a guess, the re-resolve is not doing the right thing (computed style also shows the color as red, as a note, so it's not just a painting issue).
Assignee: jst → dbaron
Status: UNCONFIRMED → NEW
Component: DOM Style → Style System
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Attached file self-contained testcase (deleted) —
Attachment #105177 - Attachment is obsolete: true
Attachment #105178 - Attachment is obsolete: true
Attachment #105180 - Attachment is obsolete: true
Attachment #105186 - Attachment is obsolete: true
Oh, and this is most definitely a bug. ;)
Keywords: testcase
This looks like a regression. I tested attachment 105224 [details] on Netscape 7.0 release....... when i click on the DIV, only the foreground color changes to blue, when i click again, the foreground color changes to red. adding KW : regression
Keywords: regression
Priority: -- → P2
This was working in build 2002-04-15-21 and was not in build 2002-04-18-08 The only checkin I see that seems blameworthy in there is for bug 128743
(Which was checked in 5 hours before the checkin window that you gave, no?)
Yep. It's a major stretch.... Often checkins from an hour or two before the window in question will actually not make the first of the two builds, but 5 hours is very unlikely... And I don't really see anything in that patch (I looked again) that would cause this. But I also see nothing in the window that seems relevant. :(
A guess as to what's happening here is that the doc sheets get out of order due to the insertion and removal of the sheet. I think our code that ensures the ordering of the stylesheets and the merging of all |nsICSSStyleSheet|s together is somewhat fragile. Maybe I'm getting confused, though...
(I actually tested this in an opt build, with a printf, but I think I wrote the assertion correctly. We have 2 sheets and insert at position 1.)
Oh, nice catch! So here's what's going on: 1) We change the href and nsStyleLinkElement::UpdateStyleSheet() gets called 2) This looks for the closest linking element _after_ ours. 3) There isn't one 4) It asks the doc how many sheets the doc has 5) The doc says "2" (attribute and inline) 6) The CSS Loader is told to load a sheet for position "2" (this is 0-based) 7) The sheetmap does it magic and discovers that we only have a sheet for position "0" so far (from the original pageload) 8) We insert a sheet at position "1" 9) HTMLDocument adds 1 for the attr sheet and sticks it in position "2". Ooops. We just put it in the cascade after the inline style sheet. So I think the simplest fix is to fix step 2--6 to work better (eg use the preceding element or 0 if there is not one).... The real fix is probably to clean up the weird document/element/sink/cssloader sheet ordering interaction... peterv? Thoughts? Any reason you went with the following element instead of the preceding one?
Assignee: dbaron → bzbarsky
Target Milestone: --- → mozilla1.3alpha
Priority: P2 → P1
incase anyone wants to know why this bug is a real pain consider the following: You write a series of gui "components" that are themed via a stylesheet, user changes are made via the style object and should be preserved ontop of stylesheet changes - as specified in the w3. You go to change the "theme" by loading a new stylesheet with user changes lost in mozilla, but retained in ie. This creates a real dilemna in creating cross browser themeable components. About the only work around I can think of is in mozilla to loop through all components and re-apply the cssText, but this seems real slow :( Anyone have an alternative work around?
Depends on: 107567
Fixed for 1.3a by checkin for bug 107567
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
verified fixed on winXP trunk build 2003-02-24-04
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: