If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Aqua menu-style selects supress background, but not foreground

RESOLVED FIXED

Status

()

Core
Widget: Cocoa
RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: Stuart Morgan, Assigned: Josh Aas)

Tracking

Trunk
x86
Mac OS X
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
The change in bug 381268 made Aqua menu-style selects discard background information, but they don't do anything about foreground, which means that if someone styles a select with a dark background and light text, you end up with light text on an essentially white background, which is really bad.

I don't have time to make a new minimal testcase at the moment, but see the "Select (as an Aqua menulist)" section of https://bugzilla.mozilla.org/attachment.cgi?id=201986 where the select should be light pink on a dark blue background.

Probably this case should fall back to non-themed widgets; alternately, the text color needs to be fixed to system text colors.
Flags: blocking1.9?
philippe somewhere has a screenshot of what WebKit does, which is probably a not-for-1.9 possibility ;)

Comment 2

11 years ago
Created attachment 265739 [details]
minimal test case

select {background:#000; color:#ff7f00;}

Comment 3

11 years ago
Created attachment 265742 [details]
screenshot of test case in WebKit

IE 7 win32 does something similar.
(Assignee)

Updated

10 years ago
Flags: blocking1.9? → blocking1.9+
(Assignee)

Comment 4

10 years ago
We have two options here - when the foreground color changes we can either suppress the change or fall back to gfx widgets.

If we want to suppress the foreground color change, how do we do that?

If we want to go to gfx widgets, I have a patch that does that with one major problem. When the dropdown widget falls back we needs its gfx dropmarker to fall back as well. Otherwise we get a gfx widget with a native dropmarker inside. Perhaps we could get the comboboxcontrolframe to say:

if (this->-moz-appearance == none && !theme->ThemeNeedsComboboxDropmarker())
  this->dropmarker_child->-moz-appearance = none;

Any ideas roc?
(Assignee)

Updated

10 years ago
Duplicate of this bug: 387031
I would prefer to back to gfx widgets.

nsComboboxControlFrame needs a method that determines whether the combobox should be themed or not. This should examine all relevant styles on the combobox, and it should be called by both the combobox frame and the dropdown marker frame.
(Assignee)

Comment 7

10 years ago
Created attachment 278480 [details] [diff] [review]
fix v1.0
Attachment #278480 - Flags: review?(cbarrett)
Comment on attachment 278480 [details] [diff] [review]
fix v1.0


>+  // if this is a dropdown button in a combobox the answer is always no
>+  if (aWidgetType == NS_THEME_DROPDOWN_BUTTON) {
>+    nsIFrame* parentFrame = aFrame->GetParent();
>+    if (parentFrame && (parentFrame->GetType() == nsWidgetAtoms::comboboxControlFrame))
>+      return PR_FALSE;
>+  }
> 
>   switch (aWidgetType) {
>+    case NS_THEME_LISTBOX:
>+      return PR_TRUE; // we always want listboxes themed, non-themed ones look wrong
>+      break;
>+

The listbox v. combobox v. dropdown terminology is a bit confusing (I've never understood what the difference is in Gecko terms). I tested the patch and it works.
Attachment #278480 - Flags: review?(cbarrett) → review+
(Assignee)

Updated

10 years ago
Attachment #278480 - Flags: superreview?(roc)
Attachment #278480 - Flags: superreview?(roc) → superreview+
(Assignee)

Comment 9

10 years ago
fixed on trunk
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.