Open Bug 1536148 Opened 2 years ago Updated 1 month ago

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

Categories

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

65 Branch
defect

Tracking

()

People

(Reporter: pBakhuis, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: dupeme, parity-chrome, testcase)

Attachments

(4 files)

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.

Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: Untriaged → Layout: Form Controls
Ever confirmed: true
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)
Duplicate of this bug: 1557716
Duplicate of this bug: 1559105

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.

Duplicate of this bug: 1608806

(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).

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