Closed Bug 1023277 Opened 6 years ago Closed 6 years ago

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

Categories

(Toolkit :: Themes, defect)

29 Branch
x86_64
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla33

People

(Reporter: RainerBielefeldNG, Assigned: philip.chee)

References

Details

Attachments

(2 files, 2 obsolete files)

Attached image 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
Possibly you might have a broken extension/addon. Try restarting SeaMonkey in safe mode:
Go Help->Restart with Add-ons Disabled.
(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.
Could it be locale related?
Perhaps test an en-US build & see what that shows?
(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.
Flags: needinfo?(kairo)
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.
Flags: needinfo?(kairo)
(In reply to Robert Kaiser (:kairo@mozilla.com) 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?
(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.
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.
I see you are using Windows. Which windows theme are you using aero? Try switching to a different theme e.g. basic.
(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
Summary: Dropdown for mail view selector: "All" an "Unread" without text instead of highlighted → Dropdown for mail view selector: "All" an "Unread" without text instead of highlighted with IWN7-Basic and Aqua Themes
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.
Summary: Dropdown for mail view selector: "All" an "Unread" without text instead of highlighted with IWN7-Basic and Aqua Themes → Dropdown for mail view selector: "All" an "Unread" without text instead of highlighted with IWN7-Basic and Aero Themes
Depends on: 814041, 853431
Attached patch WIP patch fix menulist menuitems (obsolete) — Splinter Review
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?
Assignee: nobody → philip.chee
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #8442359 - Flags: feedback?(neil)
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.)
Attachment #8442359 - Flags: feedback?(neil) → feedback-
See Also: → 1028528
Moving to toolkit -> Themes
Component: MailNews: General → Themes
Product: SeaMonkey → Toolkit
Version: SeaMonkey 2.26 Branch → 29 Branch
Attached patch Patch v1.0 Proposed fix (obsolete) — Splinter Review
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"]
Attachment #8442359 - Attachment is obsolete: true
Attachment #8445455 - Flags: review?(fryn)
Comment on attachment 8445455 [details] [diff] [review]
Patch v1.0 Proposed fix

Changing reviewer request to mossop
Attachment #8445455 - Flags: review?(fryn) → review?(dtownsend+bugmail)
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.
Attachment #8445455 - Flags: review?(dtownsend+bugmail) → review-
(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|?
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;
}
> 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...)
Attachment #8445455 - Attachment is obsolete: true
Attachment #8450382 - Flags: review?(dao)
Attachment #8450382 - Flags: review?(dao) → review+
https://hg.mozilla.org/mozilla-central/rev/c3496e9453d3
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
See Also: → 1035237
You need to log in before you can comment on or make changes to this bug.