OPTION's font-family is ignored when the parent SELECT has the same font-family
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | fixed |
People
(Reporter: websec02.g02, Assigned: emilio)
References
Details
Attachments
(3 files)
<select> from the halifax-online site reported in bug 1565798
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36
Steps to reproduce:
Visit this JSFiddle: https://jsfiddle.net/g6mdaftn/
Actual results:
OPTION tag is not styled.
Expected results:
Monospace font should be applied to OPTION tag.
|
||
Comment 1•5 years ago
|
||
WFM on macOS (the options are styled with monospace, as expected), but the bug reproduces on Windows.
This apparently being Windows-specific reminds me of bug 1565798; I wonder if there's a common underlying issue in both cases. Emilio, IIRC you worked on the <option>-styling stuff - ideas?
|
Assignee | |
Comment 2•5 years ago
|
||
Yes, this looks like bug 1565798, I'll investigate.
|
|
Assignee | |
Comment 3•5 years ago
|
||
So that fonts chosen by the author inherit into the menuitems
properly, instead of being overriden.
|
|
Assignee | |
Updated•5 years ago
|
|
|
||
Comment 4•5 years ago
|
||
I tried applying this patch locally on my Windows build, as I wanted to see how bug 1565798 looks after this change; but I'm not sure this is working as expected? E.g. looking at the month popup at https://www.halifax-online.co.uk/ib-access/cwa/forgotten-details/index.html#/your-details?_k=e8p7hz, the <option>s seem to be inheriting only the font-size from their parent <select>, and not its font-family.
|
|
||
Comment 5•5 years ago
|
||
Oh, that'll be because the <select> is using a webfont, which isn't available in the parent process. So that's a separate issue; sorry for the noise.
|
|
Assignee | |
Comment 6•5 years ago
|
||
Yeah, that's bug 1576820.
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/89521f195772 Set font family on the content select menupopup, not menuitem. r=mconley
|
||
Comment 8•5 years ago
|
||
| bugherder | ||
|
||
Updated•4 years ago
|
|
||
Comment 9•4 years ago
|
||
It seems that this bug appeared again on the current version. I've recognized that just recently working on a desing which previously did not show this issue.
Version Firefox: 72.0.2 (64-Bit), Version Chrome used for comparison: 79.0.3945.130 (64-Bit)
OS: Windows 10 Home, version 1903
Summary: CSS font family assignment does take effect on all intended html elements including select and the selected option but is incorrect on the options shown in the dropdown list.
Overview: The issue showed up due to selects including options for which the same font family was used as for the whole design. The failure was not appearing during a previous Firefox version and also never appeared on Chrome. Another (older) web design was checked for comparison and appeared to show the same issue for which it did not previously.
Steps to Reproduce: Single select item was written in a new html file with corresponding CCS, font file is located in subfolder
Actual results: Option font family incorrect on Firefox, correct on Chrome
Expected results: Correct font family display on Firefox, same as on Chrome
|
|
||
Comment 10•4 years ago
|
||
Image showing appearance on Firefox (left side) and Chrome (right side). Below the code to reproduce the failure.
--- HTML ---
<!DOCTYPE html>
<html lang="de">
<head>
<link rel="stylesheet" type="text/css" href="style.css?v={random number/string}">
</head>
<body>
<div>
<select>
<option>Item 1</option>
<option>Item 2</option>
</select>
</div>
</body>
</html>
--- CSS ---
*
{
font-family: "standard";
font-size: 1.2rem;
}
@font-face
{
font-family: "standard";
src: url("fonts/SourceSansPro-Light.otf") format("opentype");
}
|
|
||
Comment 11•4 years ago
|
||
(In reply to Daniel Brändle from comment #9)
It seems that this bug appeared again on the current version.
What you're describing is bug 1576820.
Description
•