961533 - When a lightweight theme is in use, the statusbar doesn't get the "lwthemefooter" attribute at startup, but only after changing the lightweight theme (even temporarily)

Status: RESOLVED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26a1 ID:20140117003001 c-c:385ea939531d m-c:9bcc52594322

This is probably a Toolkit bug, except that the statusbar has been removed from the latest Firefox versions. It might still belong in Toolkit if Thunderbird-Daily still has a statusbar.

When starting SeaMonkey with a lightweight theme already set, the statusbar doesn't get the "lwthemefooter" boolean attribute immediately, but only when the user changes the lightweight theme, either permanently (by enabling a different one) or temporarily (onmouseover on any lightweight theme's thumbnail). The same happens to the "style" string attribute, and yet AFAICT the lightweight theme footer is displayed. The lightweight-theme-dependent attributes on the parent "window" element _are_ set at startup.

This could make a difference in the case of theme or user CSS relying on that attribute (I have some in my userChrome.css, and that's how I noticed it); it can also be checked by means of the DOM Inspector.

This problem is cosmetic so I'm setting "trivial" severity; however it can make statusbar text unreadable if there is too little contrast between the current lightweight theme's footer background color and the statusbar text color.

Comment 1

[[e-mail]]

Worked fine for me when I tried it in a fresh build. It's possible that you have addons that are interfering with the lightweight theme. Can you try a new profile? (Obviously you can't try safe mode because that disables the theme too.)

Comment 2

[Tony Mechelynck [:tonymec]]

(In reply to [e-mail] from comment #1)
> Worked fine for me when I tried it in a fresh build. It's possible that you
> have addons that are interfering with the lightweight theme. Can you try a
> new profile? (Obviously you can't try safe mode because that disables the
> theme too.)

Obviously. It doesn't disable the lightweight theme, but it disables both userChrome.css and DOMi, and any complete theme would be disabled too, so AFAIK there's no way to know if the attribute is present then, except maybe if a try-build could be made with _default_ CSS similar to what I have in my userChrome.css, and that would be "a little" far-fetched.

Of the extensions I have, I thought the Lightweight Theme Manager was the only one likely to cause interference, so I tried disabling it, and the same symptoms were present. I'll try doing some more tests, but not today (Tuesday 21 January European time), because I have lots of things to do today AFK.

Comment 3

[Tony Mechelynck [:tonymec]]

- Contrary to what I had thought at first, the lightweight theme background is not painted at startup. This may afford us a way to check this in Safe Mode.
- I first noticed this problem while wearing a lightweight theme together with a complete theme (but thereafter I saw it with a "bare" lightweight theme too, i.e. with the look-and-feel of  of the Default theme).
  - "Marrying" a complete theme with a lightweight one is tricky, and requires three restarts (see bug 520124 comment #110), of which I've recently found out that the third one can be avoided by hovering the mouse over a lightweight theme's thumbnail after setting lightweightThemes.isThemeSelected to true. (I've only used this shortcut with the Lightweight Theme Manager extension installed, and I don't know if it makes a difference.)

Here is a user CSS snippet to make the problem more visible. The last rule is for the benefit of the ShowIP extension. I also have different rules to solve contrast problems in the top chrome, more adapted to the main vs. auxiliary nature of the lwtheme's header vs. footer, but they work so I'm not including them here. My full userChrome.css for SeaMonkey can be seen at http://users.skynet.be/antoine.mechelynck/other/userChrome-seamonkey.css

statusbar
 { text-shadow:         none                    !important
 }
statusbar:not([lwthemefooter=true])
 { color:               #CCD0DD                 !important
 ; background-color:    #666699                 !important
 }
statusbar[lwthemefooter=true]
 { color:               black                   !important
 ; text-shadow:         0px 0px 2px    white
 ,                      0px 0px 0.25em white
 ,                      0px 0px 0.5em  white
 ,                      0px 0px 0.75em white    !important
 }
/*
 * the following is a hack, it will need  adjustment
 * every time we customize the color for IPv4.
 *
 * Also, a similar rule would be needed for IPv6
 * except that I don't have IPv6.
 */
#showip_status_text[style="color:#FFFF00;"]
 /* note: no space after the colon, and semicolon at the end */
 { text-shadow:         0px 0px 2px    blue
 ,                      0px 0px 0.25em blue
 ,                      0px 0px 0.5em  blue
 ,                      0px 0px 0.75em blue     !important
 }

Comment 4

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 SeaMonkey/2.27a1 ID:20140214003001 c-c:1ce77c2f9bd0 m-c:d275eebfae04

I haven't seen the problem for some time (but note that the above is the latest Linux64 nightly so far). I'm tentatively setting WORKSFORME in the hope that the bug won't reoccur. (The CSS snippet in comment #3 is still part of my userChrome.css.)