Font-size is computed incorrectly for a collection of child elements that use mixed font families, when their shared parent sets a font-size using CSS calc that mixes vw and em units.
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
People
(Reporter: r.otten, Assigned: emilio)
References
Details
Attachments
(6 files, 1 obsolete file)
firefox 68.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
- Create a piece of layout with sibling elements that mix different font families under one shared parent element, all directly inheriting the parent's font size.
- Set a font-size on the parent element that depends on em unit values as well as viewport vw unit values. (Typical for scaling font sizes with viewport.)
Actual results:
The sibling elements end up with different sizes, due to faulty computed font size.
This effects not just font-size, but also any height, width etc. which was set to an em-unit.
Expected results:
The sibling elements should end up with the same relevant sizes.
Note this reduced test case:
https://jsfiddle.net/s3kev417/1/
First set of boxes shows the problem in Firefox, but not in Chrome.
2nd set of boxes shows the problem going away when not using the CSS calc computed fontsize.
3rd set of boxes shows the problem going away when not using different font families on different child elements.
The problem also goes away when explicitly setting the root (<html>) element's font-size to a hard px value. (But ofcourse, I can't show that in the same jsfiddle.)
|
||
Comment 1•5 years ago
|
||
Hi,
I reproduced this issue on my machine (Win 10) with Firefox Release 68, Firefox Beta 69 and Nightly 70. On Chrome works as intended. See screenshots attached.
|
|
||
Comment 2•5 years ago
|
||
|
|
||
Comment 3•5 years ago
|
||
|
|
||
Comment 4•5 years ago
|
||
|
|
||
Comment 5•5 years ago
|
||
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 6•5 years ago
|
||
|
|
Assignee | |
Comment 7•5 years ago
|
||
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 9•5 years ago
|
||
These two bugs (bug 1572738 and bug 1572451) are stylo regressions.
When font-family changes, we try to recompute the font-size with a length /
percentage combinations in case the generic family changes, so the user
preferences are kept.
When calc() is involved, we clamp to non-negative too early, via
NonNegativeLength::scale_by.
I think we should generally dump this "try to track font-size across calc()"
thingie, as as various comments note it is not quite perfect, and it's not clear
how it should work in presence of min()/max().
This patch fixes the issue and simplifies code a bit, I may consider removing
this altogether in a follow-up.
|
||
Updated•5 years ago
|
|
||
Comment 10•5 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/fa644e5bcf77 Don't clamp font-size calc() factors too early. r=manishearth
|
||
Comment 11•5 years ago
|
||
| bugherder | ||
|
||
Updated•5 years ago
|
Description
•