1644611 - ::before pseudo content overwrites select option label text

Status: NEW

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

Description

[zachsteffens]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

I'm using angularJS to generate a select list with options. The angularJS directive always appends a label to the option so you end up with

<option label="text">text</option>

It doesnt seem like there is a way to omit this label property from the generated html. This poses a problem in FF when you want to use a before pseudo element to prepend text or icons before the option. When you set content on the pseudo before it hides the label that gets displayed.

This issue can be seen demonstrated in a stackoverflow post I created here

https://stackoverflow.com/questions/62271593/dont-include-label-in-ng-options

or in a codepen here

https://codepen.io/zachsteffens/pen/xxZwXax

Some example html is included below.
In this example, I am expecting both first and second to be visible, but in FF, Second is not visible. When The label option is omitted, there is no problem. Is there a CSS workaround to make both the label and the ::before visible?

.optionClass:before{
content:"::before "
}

<select multiple="multiple">
<option class="optionClass">first</option>
<option class="optionClass" label="second" >second</option>
</select>

Actual results:

what shows on FF for windows is

::before first
::before

Expected results:

what should show is

::before first
::before second

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

This is kind of expected given how we ended up implementing <option label> in bug 40545... Except on this case this used to work because on top of the label you also had text.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

And yeah, you can effectively use content: "::before " attr(label); or such from CSS, though that probably shows duplicate labels in other browsers :(

Comment 4

[zachsteffens]

Your suggestion to use attr(label) in the css content gave me a good idea for a workaround.
I couldn't append the attr(label) to the before content because in my actual implementation I'm using some font awesome icons with different font colors so both the font-face and the color of the label were wrong. So I used a mozilla only css selector and appended the label in the after content. Just need to test to ensure that I dont get double labels anywhere.

@-moz-document url-prefix(){
.optionClass:after{
content: attr(label);
}
}

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 40545

Comment 6

[Emilio Cobos Álvarez [:emilio]]

(In reply to zachsteffens from comment #4)

I couldn't append the attr(label) to the before content because in my actual implementation I'm using some font awesome icons with different font colors so both the font-face and the color of the label were wrong. So I used a mozilla only css selector and appended the label in the after content. Just need to test to ensure that I dont get double labels anywhere.

Please don't do that, as when we fix this bug then your page will show double labels in Firefox, and may prevent us from actually fixing this...

Comment 7

[zachsteffens]

I left the codepen with the original code. But I'm working on a enterprise app that needs to be released in the next week. So I put the fix in place there. I'm not super familiar with the timeline of releases of FF so I went ahead with the fix in my code and I'll remove the workaround when the fix is deployed in FF.

Comment 8

[Chris H-C :chutten|PTO (back Jan 5)]

To fix this properly in Firefox we're waiting on bug 1481150. In the meantime we could revert bug 40545's patch and reopen. I guess it's a decision between which use cases we wish to break : |

Comment 9

[Emilio Cobos Álvarez [:emilio]]

(In reply to zachsteffens from comment #7)

I left the codepen with the original code. But I'm working on a enterprise app that needs to be released in the next week. So I put the fix in place there. I'm not super familiar with the timeline of releases of FF so I went ahead with the fix in my code and I'll remove the workaround when the fix is deployed in FF.

Why not removing the label attribute in the second option altogether? If you have the same option text inside it makes zero difference.

Comment 10

[zachsteffens]

Why not removing the label attribute in the second option altogether? If you have the same option text inside it makes zero difference.

I'm using an AngularJS ng-options directive to generate the options based on a model returned from an API. Ng-options always injects the label into the option element, there's no simple way to remove it. I could override a few hundred lines of angularJS by creating a custom ng-options directive, or I could include a few lines of css to get the same result.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

Le sad, why would they do that?

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1644611 - Add the attr(label) to option and optgroup at used value time.

We still use the ::before machinery, but we prevent author changes to
it from removing the label.

Not quite sure how I feel about this :-/

Comment 13

[Sean Voisen (:svoisen)]

Hey Emilio, is this just stalled since we don't have a great solution still?

Comment 14

[Emilio Cobos Álvarez [:emilio]]

Pretty much, I'm not a fan of this solution. The proper fix needs a lot more work.

Comment 15

[Marcela (Please NI request to Brindusa Tot)]

Hi! I was able to reproduce this issue on latest Nightly 87.0a1, Beta 86.0b5, ESR 78.7.0, and Release 85.0 on Windows 10, Ubuntu 20. and macOS 10.15.
I'll change flags accordingly.