Certain Style rules don't carry over during a theme switch.



18 years ago
7 years ago


(Reporter: jelwell, Unassigned)


({dataloss, polish})

dataloss, polish

Firefox Tracking Flags

(Not tracked)




(2 attachments)



18 years ago
This can cause severe damage to an application, as some apps base functionality
(rightfully so) on style rules.

To reproduce:
1) Launch IM (commercial)
2) login
3) open an Instant Message dialog
4) Switch themes.

Actual Results:
The Instant Message dialog is totally horked and no longer works.

Expected Results:
The Instant Message dialog maintains it's imMode style rule and works fine.

Screenshots coming.

Comment 1

18 years ago
This could also be the reason that the Mozilla app in general is known to act
buggy after a theme switch. sprinkling with keywords.
Keywords: correctness, dataloss, mozilla0.9, nsbeta1, nsCatFood, polish

Comment 2

18 years ago
Created attachment 31014 [details]
Style Before theme switch, notice the imMode= rule

Comment 3

18 years ago
Created attachment 31015 [details]
Post Theme switch, notice the lack of an imMode= rule.

Comment 4

18 years ago
Hewitt mentioned that the importing of style rules might be the problem. So I
ditched the imported imWindow.css file.

I took two more screenshots, again the pre image shows the mode rule, and the
post does not. Also, I tried commenting out the #KnockKnockOrg rule that you'll
notice in the Classic skin (just in case that mattered) but still the mode rule
is not kept during a theme switch.

Comment 5

18 years ago
jelwell, using the inspector, you should check to see if the *attribute* is 
present in the content model that you're using to do the styling.  Let's find 
out if that attribute is going away.

Comment 6

18 years ago
if by *attribute* you mean visibility, it's not set after the theme switch.


18 years ago
Target Milestone: --- → Future

Comment 7

18 years ago
any reason this was targetted for the future? This is likely the cause of
unstability in Mozilla after a theme switch. Any code that uses style attributes
programatically is apt to behave irratically after a theme switch.
Keywords: mozilla0.9.2

Comment 8

18 years ago
This is related to switching themes--goes to skinability bug though.
Component: Themes → Skinability


18 years ago
Target Milestone: Future → ---

Comment 9

18 years ago
For RTM, theme switching won't happen on live windows, so futuring.  

I last asked for verification that the attribute that is used to change modes 
had not changed its value (thus resulting in different rules matching).  Is the 
element in question retaining the attributes across a skin switch? If so, then 
the bug is correct as stated.  If not, however, then we're likely not looking 
at a skin switch bug.
Target Milestone: --- → Future

Comment 10

18 years ago
Thanks for clarification on why this has been futured.

The style rule, "#AimIM[imMode=Normal] #KnockKnockOrg" is not meant to change
it's value during a theme switch.

It changes programatically via javascript when the IM window is meant to morph
from a knock knock window into a composition window.

Looking at the screenshots in the attachments you can see that the rule simply
disappears entirely.

If that doesn't clear up your question, let me know.

Comment 11

18 years ago
Right, but does it disappear because the attribute goes away for some reason 
when the skin is switched?  The inspector will also show you what attributes 
are set on the XUL element.  I'm curious to see if all of the attributes are 
set such that the rule SHOULD still be matched, or if somethign happened during 
the switch that caused some of the attributes to become incorrect, thereby 
causing the rule to (correctly) not match.  

In other words, is the bug with XUL attributes or with CSS rules?


18 years ago
Blocks: 104166

Comment 12

17 years ago
With LittleMozilla, for the last few weeks, the mail chrome is now unfunctional.
Nothing is highlighted (the selected folder, the unread messages....). This is
the 0.98 1/15 little mozilla.


11 years ago
Product: Core → Core Graveyard


9 years ago
Assignee: hyatt → nobody
QA Contact: pmac → skinability
This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
I don't think its relevant to keep an IM bug here.  Also we don't activate a new theme until a restart any more.
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.