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.

This could also be the reason that the Mozilla app in general is known to act buggy after a theme switch. sprinkling with keywords.

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.

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.

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

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.

This is related to switching themes--goes to skinability bug though.

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.

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.

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?

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.

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.