Page MenuHomePhabricator

Firefox renders the open dropdown states for <select /> inputs with a "color" style in a primitive way
Closed, ResolvedPublic


From Z1336#44372, the dropdown menus have changed causing feelings of unease and general illness

Observed on Firefox 54 on Mac OSX, on a Differential page

Screen Shot 2017-07-19 at 3.38.53 PM.png (213×326 px, 44 KB)
Screen Shot 2017-07-19 at 3.39.01 PM.png (222×315 px, 37 KB)

Mid-April: 517372a1e0c48d0bc1961af06e132b8537776565
Last-Monday: 5ad86a1052d1a03222d52fe87afd6be9fe5ced15

Event Timeline

I can't prove it but it feels like the new style is a bit sensitive to selecting an item -- sometimes when opening the dropdown menu the first item auto-selects and closes immediately. I can't prove it though.

FWIW, ours looks the same as every dropdown I can find on other websites using Firefox 54, Mac. Do you have an example site that looks like your "Mid-April" install.

Not particularly - I copied the select HTML into a "Tryit Editor" from W3:

With the same Firefox/OSX it has a dropdown that's similar to the "Mid-April"

Screen Shot 2017-07-19 at 4.36.06 PM.png (178×294 px, 29 KB)

If we think it's a CSS change, and not a FF issue, going to have to bisect for it. No matter what I do, I can't get that menu to look like that on Firefox.

Errr I may need to investigate further - this install has the same "Mid-April" style using this same browser. I noticed this change on our test instance after upgrading to the latest. We don't inject any styles/js or anything so I'm not sure why that instance would be different.


The difference appears when using High-Contrast vs. Regular-Type

"Mid-April" = High-Contrast
"Last-Monday" = Regular-Type

Disregard the different installs - I can reproduce on this install as well just by switching High-Contrast on/off.

So this may be invalid? @cspeck just had to turn on High-Contrast on the test install~

I don't know, I mean, I'd like to understand what triggers it to look so much better, but it's not a regression it sounds.

It's the color of <select>

In cspeck's-preferred-style:

select {
  color: #000;

In cspeck's-style-of-woe:

select {
  color: #464C5C;

At least, change from 464C5C to 000 when using Default Mode (not High Contrast), caused the menu to appear in the same fashion as High Contrast

I still can't reproduce it locally. Tried colors, tried high-contrast.

Hmm I've tried on two separate OSX machines using Firefox and can reproduce

It uh, took me a few seconds to remember what I'm doing in the inspector

It seems like a bug in FF to me

I think (?) this reproduces for me, too:

Screen Shot 2017-07-19 at 2.40.22 PM.png (1×637 px, 189 KB)

The expected case doesn't reproduce for me

All my firefox tests, as expected, look like 💩 😦

it might have something to do with appearance.

Is this the current status here?

  • @chad can't reproduce this.
  • @cspeckmim narrowed this down to color: ... on the <select />.
  • There's probably no reason for us to have color: ... on the <select />, and it's just bleeding in from some parent class?

(I'm not sure what appearance is.)

If so, since I can reproduce this, I'll do this?

  • Add an override rule or adjust whatever's setting color: ... on the <select />.
  • Test it locally.
  • We'll leave the question of why @chad can't reproduce it as a mystery for the ages.

While checking again I noticed:

  1. Explicitly setting the color: to #000 changes Last-MondayMid-April
  2. Removing/unchecking the color: in the web inspector doesn't have any effect, it looks like because <select /> elements are inheriting that style in two ways. Removing/unchecking from both definitions/rules will change it Last-MondayMid-April

There's probably no reason for us to have color: ... on the <select />

Well, it's an explicit rule on a select { ... } rule here, so maybe I'm mistaken about this:;e47f85cd98b869fe97b3e6143f5de0670039d6da$111

This rule does have an effect -- styling the default state of the input in Firefox, Chrome, and Safari;

Screen Shot 2017-07-27 at 6.43.48 AM.png (110×294 px, 9 KB)

Removing the rule alone just causes this rule to take effect instead:;e47f85cd98b869fe97b3e6143f5de0670039d6da$25

Removing both rules, or replacing the rule in the first link with color: inherit, fixes the "dropdown open" state for me.

Screen Shot 2017-07-27 at 6.47.21 AM.png (196×341 px, 28 KB)

Removing the appearance: ... rule does not affect the dropdown state.

Here's a minimal file which reproduces the issue for me when saved to the desktop and opened in Firefox:

<select style="color: orange">


Screen Shot 2017-07-27 at 6.49.39 AM.png (179×144 px, 10 KB)

There are a bunch of similar issues in Firefox's tracker, although none seem like especially good fits here:

In the short term, I suspect our options are either:

  • color the default state of <select /> inputs; or
  • have nice dropdown menu states in Firefox.

These seem about equivalent to me so I think this is a design call.

We could also file a bug against Firefox, but, e.g., in Chrome has now been open for two years even though I filed it with a minimal reproduction case and this seems likely to have some of the same hallmarks of bizarreness and complexity, and isn't unambiguously a bug.

Per above, the decision to color the default state is explicit so this is likely just a design tradeoff in the short term. I can test things locally if you want to keep fishing.

epriestley renamed this task from Dropdown styles menu on Firefox/OSX has changed to Firefox renders the open dropdown states for <select /> inputs with a "color" style in a primitive way.Jul 27 2017, 2:00 PM
epriestley triaged this task as Wishlist priority.
epriestley added a project: Firefox.

I honestly can't get the cool looking macos dropdown on firefox no matter what I try.

Let me know if that diff works.