Open Bug 1376443 Opened 7 years ago Updated 2 years ago

Select option inherited background-color differs between initial focus/open state and subsequent focus/open states

Categories

(Core :: Layout: Form Controls, defect, P3)

54 Branch
defect

Tracking

()

UNCONFIRMED
Tracking Status
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- ?

People

(Reporter: hulbert.jason, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(6 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce: macOS 10.12.5 (16F73) First Scenario: - Apply a background-color to a select element - Click to initially focus and open the select drop Second Scenario: - Apply a background-color to a select element - Click to initially focus and open the select drop - Select an option - Click to open the select drop again Third Scenario: - Apply a background-color and color to a select element - Apply a transition for the background-color - Click to initially focus and open the select drop Actual results: - In the first scenario, background-color IS NOT inherited by option elements. - In the second scenario, background-color IS inherited by option elements. - In the third scenario, when the transition duration completes, the options abruptly inherit background-color. Expected results: Background-color (or any relevant styles) applied to select elements should be consistently inherited by option elements across states. Or, better yet, don't allow styling of option elements at all.
Could you attach a testcase, please.
Flags: needinfo?(hulbert.jason)
Keywords: testcase-wanted
(In reply to Loic from comment #3) > Could you attach a testcase, please. Here's a Codepen demonstrating the issue. UPDATE: While setting up the test case, I realized that this behavior only occurs when the `:-mos-focusring` psuedo is used on the select element in question. https://codepen.io/jasonhulbert/pen/xrPjXx
Flags: needinfo?(hulbert.jason)
Keywords: testcase-wanted
I'm notsure if I understand the testcase. I have the same result with Chrome and FF. Could you attach screenshot of the codepen result.
Blocks: e10s-select
(In reply to Loic from comment #5) > I'm notsure if I understand the testcase. I have the same result with Chrome > and FF. Could you attach screenshot of the codepen result. I'll attempt to restate the steps with additional clarity as well as post some additional images. To be clear, this issue does not occur in Chrome. I'm only referring to FF 54 on macOS. I also made the "focus" background color in the pen red to make the difference more obvious. 1. When the testcase loads, the select field will have it's "normal" appearance (not focused, in other words). I'm using the word "normal" in the most generic way - I'm simply describing the initial, default state of the select field. I'm not using the word "normal" to describe any author styles or browser styles. 2. As expected, clicking the select field will set the "focus" state as well as open/show the select drop menu. Notice that the options drop menu DOES NOT have the background-color as set on the select element. 3. Either select an option or otherwise blur the select field. Now, click the select field again. Notice that the options drop menu now DOES have the background-color as set on the select element. 4. The second select field has identical properties to the first except that there is a transition assigned to background-color property. Here, you will see the change in the option drop menu appearance after the transition duration completes. 5. If you remove the selector and style block for ".custom-select:-moz-focusring { ... }", this issue goes away.
Attached image Active appearance of select element (deleted) —
Priority: -- → P3
I tested the test case in comment 4. For the first field: The bg-color of options menu is always red no matter it is the initial focus or not. For the second field: I think we use native UI for the options menu w/o bg-color, and use our custom UI for the options menu w/ bg-color. So, after the transition finished, bg-color is applied to the options menu, and the UI would switch to our custom UI from native UI. That's why you feel the options menu inherit background-color abruptly. In my opinion, there no bug for the first field. And I'm not sure what is the best way to fix the second field with a bg-color transition. Maybe we should always use our custom UI for the options menu w/ bg-color transition.
Blocks: e10s-select-styling
No longer blocks: e10s-select
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: