Firefox Select List Font Metrics/Rendering Glitch (macOS)
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: dejanyy, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression, testcase)
Attachments
(3 files)
|
A simple HTML file that illustrates the problem (using Firefox 104.0.2 and Montserrat font on macOS)
856 bytes,
text/html
|
Details | |
|
96.53 KB,
image/png
|
Details | |
|
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
C_selected.png
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:104.0) Gecko/20100101 Firefox/104.0
Steps to reproduce:
I created the following HTML page and opened it using Firefox 104.0.2 (64-bit) on macOS (Intel):
<!DOCTYPE html>
<html>
<head>
<title>Firefox Select List Font Metrics/Rendering Glitch (macOS)</title>
<style>
@import url('https://fonts.googleapis.com/css?family=Montserrat:400');
body, input, select { font-family: 'Montserrat', sans-serif; font-size: 18px; }
</style>
</head>
<body>
<h1>Firefox Select List Font Metrics/Rendering Glitch (macOS)</h1>
<h2>Instructions</h2>
<p>Click the Select List below and choose option C. Click the Select List again to expand it. Letter C is missing. Only the checkmark is visible.</p>
<select>
<option value="A">A</option>
<option value="B">B</option>
<option value="C">C</option>
</select>
<h2>Environment</h2>
<ul>
<li>macOS (Intel)</li>
<li>Firefox 104.0.2 (64-bit)</li>
<li>Montserrat font (https://fonts.googleapis.com/css?family=Montserrat:400)</li>
</ul>
</body>
</html>
Actual results:
Letter C was not displayed in the drop-down list when option C was selected. Only the checkmark was shown.
Expected results:
A checkmark and letter C should be displayed when option C is selected.
|
||
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
|
||
Comment 3•2 years ago
|
||
The severity field is not set for this bug.
:dholbert, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 4•2 years ago
|
||
Thanks for the bug report! I can reproduce. I don't have a mac physically available (traveling at the moment), but I tested macOS via BrowserStack.
BrowserStack let me test different Firefox versions too, and it seems that Firefox 102 is the first affected release. Firefox 101 release is unaffected.
Firefox 105 and 106beta (the latest I can test at the moment) are affected as well. I assume 107 Nightly must be affected too; setting that flag speculatively.
jfkthame, maybe you could take a look & bisect further to find out what regressed this in 102?
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
||
Comment 5•2 years ago
|
||
I tried to reproduce this, but it doesn't seem to happen for me (with either Nightly or Firefox release versions) using the testcase here.
|
||
Comment 6•2 years ago
|
||
Hello! Reproduced the issue on macOS 10.15.7 but I could not reproduce it on macOS 11 with Firefox 106.0b8. Here is the regression range:
Last good revision: be91ae588a2526842affc322b0672e501e20d841
First bad revision: 2662564f566cd0eae2963c73f1c573e16331eb3a
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=be91ae588a2526842affc322b0672e501e20d841&tochange=2662564f566cd0eae2963c73f1c573e16331eb3a
Potential regressor: bug 1703866
Emilio, it seems that the patch from bug 1703866 caused this issue, can you please have a look? Thank you!
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Comment 7•2 years ago
|
||
I can reproduce this. The issue here is that on XUL layout width sets the
preferred width, but content might still expand the box size. In my machine the
checkmark is 15.01px, which is enough to break the math and push the C away.
Switching away from XUL flex into modern flex would fix it, but meanwhile this
achieves the same effect and fixes the bug.
Seems hard to add an automated test for this...
|
|
Assignee | |
Comment 8•2 years ago
|
||
Comment on attachment 9297416 [details]
Bug 1791108 - Ensure macOS checked checkmark is actually 15px. r=jfkthame,mstange,spohl
Beta/Release Uplift Approval Request
- User impact if declined: Some select menus on macos may have cropped characters at the end
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: comment 0
- List of other uplifts needed: none
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Really simple CSS patch.
- String changes made/needed: none
- Is Android affected?: No
|
|
Assignee | |
Updated•2 years ago
|
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d938816c9cd1 Ensure macOS checked checkmark is actually 15px. r=jfkthame
|
||
Comment 10•2 years ago
|
||
Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/autoland/rev/3025b63e8060 Keep width to keep menulist-shrinkwrap-1.xhtml passing.
|
||
Comment 11•2 years ago
|
||
Comment on attachment 9297416 [details]
Bug 1791108 - Ensure macOS checked checkmark is actually 15px. r=jfkthame,mstange,spohl
Minimal CSS patch, I think we can take it in the last beta even if we don't have nightlies with it yet.
|
|
||
Comment 12•2 years ago
•
|
||
| bugherder uplift | ||
|
||
Comment 13•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/d938816c9cd1
https://hg.mozilla.org/mozilla-central/rev/3025b63e8060
|
||
Updated•2 years ago
|
|
||
Comment 14•2 years ago
|
||
Reproduced the issue on Firefox 106.0a1 (2022-09-15) on macOS 13 by using the TC provided in Comment 0.
The issue is verified on Firefox 106.0b8 and Firefox 107.0a1 (2022-10-06) on the same system.
|
|
||
Updated•1 year ago
|
Description
•