1023277 - Dropdown for mail view selector: "All" an "Unread" without text instead of highlighted with IWN7-Basic and Aero Themes

Status: RESOLVED FIXED

(Toolkit :: Themes, defect)

Description

[Rainer Bielefeld]

Attachment: screenshot.png

Mail Client Dropdown for mail view selector: "All" an "Unread" without text instead of highlighted while mouseover.

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
Build-Identifikator: 20140428215944

Comment 1

[Philip Chee]

Possibly you might have a broken extension/addon. Try restarting SeaMonkey in safe mode:
Go Help->Restart with Add-ons Disabled.

Comment 2

[Rainer Bielefeld]

(In reply to Philip Chee from comment #1)
> Go Help->Restart with Add-ons Disabled.

That did not heal the problem. I also tried a different profile for what only Chatzilla, DOM Inspector and JavaScript Debugger are installed: problem also appeared. I will try an unzipped version parallel to my installed one, soon.

Comment 3

[therube]

Could it be locale related?
Perhaps test an en-US build & see what that shows?

Comment 4

[Philip Chee]

(In reply to therube from comment #3)
> Could it be locale related?
> Perhaps test an en-US build & see what that shows?

Missing strings is one way to cause the problem. However normally the [de] localizer won't sign off unless his (or her) dashboard indicates all strings have been translated. I can't remember who is the current translator though.

Comment 5

[Robert Kaiser]

1) I am the German localizer for SeaMonkey, still.
2) 2.2.6 has no missing strings in German.
3) Missing strings would not cause this because we run a localization merge that put the en-US strings in for any missing strings.
4) This works fine for me in my German Nightly build and those strings haven't changed in a long time.

Comment 6

[Rainer Bielefeld]

(In reply to Robert Kaiser (:[e-mail]) from comment #5)
> 2) 2.2.6 has no missing strings in German.
  It is a vanishing string problem, not a missing string problem. If I toggle with
  mouse pointer between "Ungelesen" and "Alle" the string with current mouseover 
  disappears.

I unzipped a 2.26installer.zip - how can I force that one to ignore existing User Profiles?

Comment 7

[therube]

(backup first)

You can use Profile Manager to create, use, a new Profile.
Tools | Switch Profile... -> Manage Profiles...-> Create Profile...

Or you could start seamonkey.exe with the -ProfileManager (or -P) switch.

Comment 8

[Rainer Bielefeld]

For me the problem persists with
(a) New unzipped German Seamonkey 2.26
(b) Renamed Profile
(c) Launched New unzipped German Seamonkey 2.26
    (New Mozilla\Seamonkey profile created)
(d) created new E-Mail POP3 Account
(e) Checked function for empty Inbox folder:
    Dropdown text "All" or "Unread" vanishes while its line becomes highlighted 
    when mouseover. The highlight is rather pale while the other items in the 
    Dropdown become highlighted with a colorful blue when mouseover.

Comment 9

[Philip Chee]

I see you are using Windows. Which windows theme are you using aero? Try switching to a different theme e.g. basic.

Comment 10

[Rainer Bielefeld]

(In reply to Philip Chee from comment #9)
> Try switching to a different theme e.g. basic.

I can heal the problem with Themes "Contrast No 1", "WIN Classic"
All Aqua Themes and also AIN7 Basic show the problem

Comment 11

[Philip Chee]

This is fallout from Bug 814041 and Bug 853431

Bug 814041 - Fix menulist (folder picker) item padding and active text color on Windows XP
https://hg.mozilla.org/mozilla-central/rev/c15696ed3d83

Bug 853431 - Fix menulist active (hover) text color on Windows 7 and up
https://hg.mozilla.org/mozilla-central/rev/c15696ed3d83

Also see Thunderbird Bug 861933.

Comment 12

[Philip Chee]

Attachment: WIP patch fix menulist menuitems

This fixes the menuitem[type="radio"] but as you can see from the screenshot the last two items "Save View as a Folder…" and "Customize…" are misaligned. Perhaps this should be fixed in toolkit menu.css instead?

Comment 13

[[e-mail]]

Comment on attachment 8442359 [details] [diff] [review]
WIP patch fix menulist menuitems

Mixing radio menuitems and submenus in with a menulist isn't really something you normally see in the UI. (I don't even like the folder submenus, but sadly my folder tree dropdown never caught on.)

In the mean time, view picker hacks currently live in primaryToolbar.css

In order to get all of the menu[item]s to line up, try giving them the appropriate iconic class, the style rules for those tend to be less inconsistent. (But check that it still looks OK on the Mac.)

Comment 14

[Philip Chee]

Moving to toolkit -> Themes

Comment 15

[Philip Chee]

Attachment: Patch v1.0 Proposed fix

Fix Fallout/Regression from Bug 814041 and Bug 853431.

> +.menulist-menupopup > menuitem[type="radio"],
> +menulist > menupopup > menuitem[type="radio"],

Add rules for menuitem[type="radio"]

Comment 16

[Philip Chee]

Comment on attachment 8445455 [details] [diff] [review]
Patch v1.0 Proposed fix

Changing reviewer request to mossop

Comment 17

[Dão Gottwald [:dao]]

Comment on attachment 8445455 [details] [diff] [review]
Patch v1.0 Proposed fix

> .menulist-menupopup > menuitem,
> menulist > menupopup > menuitem,
>+.menulist-menupopup > menuitem[type="radio"],
>+menulist > menupopup > menuitem[type="radio"],
> .menulist-menupopup > menu,
> menulist > menupopup > menu {

'menuitem[type="radio"]' is already matched by 'menuitem', i.e. it's redundant in this rule. With what other rule's specificity are you fighting with here? This needs to be either fixed differently or documented clearly such that this code is maintainable rather than a mystery to everyone reading it.

Comment 18

[Philip Chee]

(In reply to Dão Gottwald [:dao] from comment #17)
> Comment on attachment 8445455 [details] [diff] [review]
> Patch v1.0 Proposed fix
> 
> > .menulist-menupopup > menuitem,
> > menulist > menupopup > menuitem,
> >+.menulist-menupopup > menuitem[type="radio"],
> >+menulist > menupopup > menuitem[type="radio"],
> > .menulist-menupopup > menu,
> > menulist > menupopup > menu {
> 
> 'menuitem[type="radio"]' is already matched by 'menuitem', i.e. it's
> redundant in this rule. With what other rule's specificity are you fighting
> with here? This needs to be either fixed differently or documented clearly
> such that this code is maintainable rather than a mystery to everyone
> reading it.

I poked at this with the DOM Inspector. Without this patch the following rule takes precedence:

http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/windows/global/menu.css?rev=c15696ed3d83#242

242 menuitem[type="radio"] {
243   -moz-appearance: radiomenuitem;
244 }

This makes the display of radio type menuitems *in* menulists different from the other descendants of menulist. Where would be the best place to make these menuitems |-moz-appearance: none|?

Comment 19

[Dão Gottwald [:dao]]

Seems like you could just add !important to -moz-appearance: none. Or maybe change the other rule like this:

:not(menupopup) > menuitem[type="radio"],
:not(menulist) > menupopup > menuitem[type="radio"] {
  -moz-appearance: radiomenuitem;
}

Comment 20

[Philip Chee]

Attachment: Patch v2.0 Use !important

> Seems like you could just add !important to -moz-appearance: none. Or maybe 
> change the other rule like this:

> :not(menupopup) > menuitem[type="radio"],
> :not(menulist) > menupopup > menuitem[type="radio"] {
>   -moz-appearance: radiomenuitem;
> }

This didn't work because now another rule takes precedence.

menuitem[checked="true"] {
  -moz-appearance: checkmenuitem;

Instead of going down a rabbit hole chasing cascading rules, I'm now using !important as you suggested.

(Personally I prefer not to use !important unless nothing else works...)

Comment 21

[Philip Chee]

Inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/c3496e9453d3

Comment 22

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/c3496e9453d3