Open Bug 1536148 Opened 6 years ago Updated 2 months ago

font-family isn't honored in `<option>` element within `<select>` dropdown

Categories

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

Product:
Core
Component:
Layout: Form Controls
Version:
65 Branch
Type:
defect

Tracking

()

People

(Reporter: pBakhuis, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: dupeme, parity-chrome, testcase)

Attachments

(5 files, 1 obsolete file)

Chrome vs Firefox (Chrome's handling of it is the correct one imo)
7.80 KB, image/png
Details
testcase 1 (for whether font-family is honored in option)
615 bytes, text/html
Details
testcase 2 (reporter's testcase)
383 bytes, text/html
Details
Rendering of incorrect OPTION font
58.64 KB, image/png
Details
Test-case from above in a standalone file.
1.66 KB, text/html
Details

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

Steps to reproduce:

I was trying to add some icons to select/option element. The icons are from font awesome I have made a fiddle over here:
https://jsfiddle.net/2euo1vk0/2/

Actual results:

The icons show up in the <select> element, but not in the dropdown (the <option> elements).
This is very odd behaviour and I doubt that it's working as intended.

I have attached an image with Chrome's output (expected) vs Firefox's on the same page.

Expected results:

The icons should show up fine in the dropdown as well.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
20190318133954

This seems like a duplicate, but I couldn't find an existing report.

Blocks: e10s-select-styling
URL: https://jsfiddle.net/2euo1vk0/2/
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: Untriaged → Layout: Form Controls
Ever confirmed: true
Keywords: dupeme, parity-chrome, testcase
Product: Firefox → Core

It looks like font-family isn't respected at all for the <option> element. (I tried font-family:monospace or serif, and neither were respected.)

This might be roughly a dupe of bug 1409638 (which is about font-size but might really be a more general issue).

Priority: -- → P3

(In reply to Daniel Holbert [:dholbert] from comment #2)

It looks like font-family isn't respected at all for the <option> element. (I tried font-family:monospace or serif, and neither were respected.)

This might be roughly a dupe of bug 1409638 (which is about font-size but might really be a more general issue).

font-family should work in all platforms but Linux since bug 1375476. Bug 1338283 is the issue that block enabling it on Linux.

However, we render the popup in the parent process, so @font-face is out of the equation... Seems like WebKit has the same issue, actually.

Jaws, two questions:

  • Do you know what needs to happen to be able to enable custom option styling on Linux? It looks fine here on Fedora... What changes can / should we do on our side?

  • Do you know if somebody did research how Blink renders the select popup? It looks like they respect the @font-face, but they also, e.g., show the options outside of the window, which looks really interesting (since it means they either send the fonts to the parent process somehow, which would be scary, or do the rendering on the child process but somehow stash that into a texture in the parent process... Or something?).

Flags: needinfo?(jaws)

Update: not a dupe of bug 1409638 -- that one is actually fixed in Nightly via bug 1375476.

However, this bug here isn't fixed (on linux). Here's a testcase to compare dropdowns with monospace vs. serif as the font-family. Neither actually gets used in the dropdown menu, on Linux (though they do get used in the dropdown button -- i.e. it's honored on the select, but the option seems to just fall back to a system font).

See Also: → 1375476
Summary: html entities using a custom font/private unicode space do not appear in option element → font-family isn't honored in `<option>` element within `<select>` dropdown

(In reply to Daniel Holbert [:dholbert] from comment #4)

Created attachment 9051828 [details]
testcase 1 (for whether font-family is honored in option)

It works if I use option as selector instead of the .mono or .serif class, at least until the mouse is over the option, at which point it reverts back to the default font.

(Sorry -- so after chatting with emilio a bit, it seems my observations in comment 2 and comment 4 were mostly a separate linux-specific issue, which is basically a version of bug 1406865. Whereas, the bug reported in comment 0 here is a more subtle thing which is not linux-specific.)

(In reply to Gingerbread Man from comment #5)

at least until the mouse is over the option, at which point it reverts back to the default font.

Filed bug 1536264 for this issue.

Interestingly extending the menu in other ways - like adding a multiple attribute to the <select> or a size attribute with a value higher than 1 does make the icons show up.

Test case:
https://jsfiddle.net/ewk6rhu4/

Yeah, that is expected, the only special-case is the size=1 dropdown, which we render out-of-process.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

(In reply to Daniel Holbert [:dholbert] from comment #2)

It looks like font-family isn't respected at all for the <option> element. (I tried font-family:monospace or serif, and neither were respected.)

This might be roughly a dupe of bug 1409638 (which is about font-size but might really be a more general issue).

font-family should work in all platforms but Linux since bug 1375476. Bug 1338283 is the issue that block enabling it on Linux.

However, we render the popup in the parent process, so @font-face is out of the equation... Seems like WebKit has the same issue, actually.

Jaws, two questions:

  • Do you know what needs to happen to be able to enable custom option styling on Linux? It looks fine here on Fedora... What changes can / should we do on our side?

As far as I remember, it is only bug 1338283 that needs to get fixed for Linux support.

  • Do you know if somebody did research how Blink renders the select popup? It looks like they respect the @font-face, but they also, e.g., show the options outside of the window, which looks really interesting (since it means they either send the fonts to the parent process somehow, which would be scary, or do the rendering on the child process but somehow stash that into a texture in the parent process... Or something?).

No I didn't dig deeper in to Blink and I'm not sure if anyone else has.

Flags: needinfo?(jaws)

Not sure if you're looking for more info on this, but here's a pen detailing how to work around the issue.
https://codepen.io/johnnyquest/pen/yLBgYwq?editors=1100

The styles applied directly to the <option> element seem to be ignored unless the declaration is logically different from that of the parent.

(In reply to haxxorztotehmaxxorz from comment #14)

Not sure if you're looking for more info on this, but here's a pen detailing how to work around the issue.
https://codepen.io/johnnyquest/pen/yLBgYwq?editors=1100

This test is mistaken; the different case is actually falling back to system fonts, and you probably happen to have them installed. If you use a font not currently installed it behaves as you would expect anything to do.

It seems I'm getting this problem starting with FF 72 on Windows, it did not occur with FF 71. The problem can be seen with Mantis, e.g. on the demo system:

https://www.mantisbt.org/bugs/view_all_bug_page.php

(select one of the filters to make a select appear).

The OPTION has its own font-family style, using the same font that is also used for the SELECT, and which is also available. When disabling the font-family rule for the OPTION, the correct font (inherited from the SELECT) is displayed.

Also see new attachment.

(In reply to Michael Hohner from comment #16)

It seems I'm getting this problem starting with FF 72 on Windows, it did not occur with FF 71. The problem can be seen with Mantis, e.g. on the demo system:

https://www.mantisbt.org/bugs/view_all_bug_page.php

(select one of the filters to make a select appear).

The OPTION has its own font-family style, using the same font that is also used for the SELECT, and which is also available. When disabling the font-family rule for the OPTION, the correct font (inherited from the SELECT) is displayed.

So this case is different. The <option> effectively has: font-family: "Open Sans". Note how there's no fallback to sans-serif or arial or such.

The change in 72 is that we started honoring that, but given it's a web font, and we can't render the web font in the parent process, we fall back to the default font of the system. This should be fixable if you specify a sensible fallback, or use font-family: revert for the <option> (which would give you the pre-72 behavior, that is, the default font-family of your system).

Hey all! I just bumped into this issue, I am on a Mac, OS version 12.1 and Firefox 96.0.2 (64-bit).
The select options are showing a serif font instead of the sans-serif font set on the element.
Font size and colors seems to be respected but not the font-family.

Can you attach a test-case? Is it just using a web font on the select?

I definitely can. What's the best way to do that Emilio?
Can I use a website like codepen or jsfiddle?

(In reply to marlon.marcello from comment #23)

I definitely can. What's the best way to do that Emilio?
Can I use a website like codepen or jsfiddle?

I believe browser engineers would prefer standalone html testcase (similar to comment 4, attaching via "Attach New File" ), but codepen or jsfiddle also work.

Attached file firefox-bug-1536148.zip (obsolete) —

Small demo for Bug 1536148

Let me know what you guys think of this:
https://bugzilla.mozilla.org/attachment.cgi?id=9260025

It's a simple index.html and index.css. In there I use a google font and some web safe fonts as well.
Notice that on the first <select> element where it should inherit the font family, the <options> are displaying a different font.

Honestly, It could be my lack of understanding about the styles and I apologize in advance, but I still would love to hear the reasoning on what I could be doing wrong.

Thanks, that's great! Here's it as a single file (which is a bit nicer since it allows loading it directly).

Attachment #9260025 - Attachment is obsolete: true

(In reply to marlon.marcello from comment #26)

Notice that on the first <select> element where it should inherit the font family, the <options> are displaying a different font.

That's expected. We can't use the web font in the select menulist, because it is rendered in a separate process.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #28)

(In reply to marlon.marcello from comment #26)

Notice that on the first <select> element where it should inherit the font family, the <options> are displaying a different font.

That's expected. We can't use the web font in the select menulist, because it is rendered in a separate process.

I see, so the problem is only with external fonts? Would that be the case too if I had downloaded the font and was using it directly from a directory?

I can confirm that this bug exist with web fonts.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #28)

That's expected. We can't use the web font in the select menulist, because it is rendered in a separate process.
So we have to accept Firefox with this bug or use Chrome?

(In reply to marlon.marcello from comment #29)

I see, so the problem is only with external fonts? Would that be the case too if I had downloaded the font and was using it directly from a directory?

Yes, if the font is installed locally, then it should work.

So we have to accept Firefox with this bug or use Chrome?

It's a limitation of how we render the <select> popup, yes. FWIW, it has different security properties than what Chrome is doing. Afaict, Chrome is allowing renderer-controlled content to be in a popup that can can go out of the browser window and over the browser UI, which seems a bit sketchy to me. But yeah, this is a bug, it's just that it's unclear what's the right way of fixing it, and what amount of work would that entail.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #31)

Yes, if the font is installed locally, then it should work.

(except not on Linux yet, per comment 3 and bug 1406865)

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)

S3 seems fair here. Specially since it doesn't work on macOS in other browsers either.

Flags: needinfo?(emilio)

I think it can be solved by using html DIVs and css to show a simple select box element and don't use separate process for this purpose.
these are some demos : https://freefrontend.com/css-select-boxes/
Browser also can use this method to show a simple select box and i think it is not so hard for developers and don't have many side effects....

(In reply to Ehsan Ch from comment #35)

I think it can be solved by using html DIVs and css to show a simple select box element and don't use separate process for this purpose.
these are some demos : https://freefrontend.com/css-select-boxes/
Browser also can use this method to show a simple select box and i think it is not so hard for developers and don't have many side effects....

This in nearly all senses is not a solution. Sure you can do it, but the entire point of fixing the issue is to not have to perform silly workarounds.

(In reply to drakeirving from comment #36)

This in nearly all senses is not a solution. Sure you can do it, but the entire point of fixing the issue is to not have to perform silly workarounds.
I didn't suggested it as a workarounds. i suggest completely redesign of select box in a simple way that didn't depend on other processes...

I suggest an alternative approach using HTML DIVs and CSS to create a custom dropdown, which avoids the separate process problem. Check out some demos here: https://forfrontend.com/css-dropdown-buttons/. This method is straightforward for developers and has minimal side effects.

That said, this is just a workaround. The ultimate goal should be to fix the browser bug to ensure proper functionality without relying on custom solution

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: