1577305 - Minimum font size setting not used in calculating font based CSS lengths

Status: RESOLVED INCOMPLETE

(Core :: Layout: Text and Fonts, defect, P5)

Description

[Rob Schlüter]

Attachment: test.html

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

Steps to reproduce:

View a HTML page with a paragraph that has CSS properties width set to 50ch and line-height to 3ex.

The menu option 'Zoom'|'Zoom text only' is active.

Set 'Minimum font size' of Firefox to 'None' and zoom out. The width of the block and line height all shrink evenly with the text size.

Reset zoom level, set 'Minimum font size' to 16. Zooming out will now stop the font shrinking but the block width and line height keep getting smaller.

Actual results:

The result is that less than the defined 50 characters fit on a line and lines overlap.

Expected results:

The width and line height should respect the actual size of the font as it is displayed.

Comment 1

[Sebastian Padilla]

Hi Rob,

I'm very sorry for the delay in answering you. I was unable to reproduce this issue on Windows 10 Pro with Firefox Nightly 71. But maybe you can provide me with a bit more info.

Does this issue occur with a fresh profile? you can find the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Can you please download Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem and see if the issue still occurs there as well?

If after doing this you can still reproduce the bug, could you send me a screenshot or a video of the bug? That always helps a lot.

Thanks in advance,

Best whishes!

Sebastian.

Comment 2

[Rob Schlüter]

Attachment: normal.png

Sample page with default options

Comment 3

[Rob Schlüter]

Attachment: 50-percent-no-minimum-font-size.png

Zoomed out sample page with no errors

Comment 4

[Rob Schlüter]

Attachment: 50-percent-minimum-font-size-20.png

Zoomed out page with overlapping lines that are also too narrow

Comment 5

[Rob Schlüter]

A fresh install of Firefox Nightly 64 bit on a Windows 10 Enterprise running as Virtualbox image still has the issue.

I added 3 screen captures that show a test page.

1. normal.png: a test page with all default settings, looks ok .

2. 50-percent-no-minimum-font-size.png: the same page at 50% size, also ok.

3. 50-percent-no-minimum-font-size.png: the same page at 50% size showing the error. Changed settings:

   • the Advanced font option Minimum font size set to 20.
   • the menu setting View | Zoom | Zoom text only activated.

The errors are:

• the lines are narrower than the 50 characters that are defined in CSS.
• lines overlap vertically because the line height is too small.

To me, it looks like the calculation of the values with ch and ex units, and probably em also, does not use the actual size of the font as it is displayed. Instead it uses the size it would be with a minimum font size of None.

Comment 6

[Rob Schlüter]

Image 3 from the previous comment should be 50-percent-minimum-font-size-20.png.

I could not find an edit option on the previous comment. And also no way to include the images with the comment.

Comment 7

[Sebastian Padilla]

Hi Rob

Thanks for double checking this as well, it really helps. Would you be so kind to tell me the version number of the Firefox Nightly that you've used?

Thanks in advanced!

Best wishes,

Sebastian

Comment 8

[Rob Schlüter]

The software has updated automatically, not the ideal choice I think for development versions, so I can't see what the version was at the exact moment I did the test.

It must have been the version that was active an hour and a half (the estimated time it to collect the requested information) before I posted images and the explaining comment.

But the issue has been around for many versions, so any version released from a few years back until now probably behaves the same.

rob

Comment 9

[Sebastian Padilla]

Hi Rob:

Thanks again for your feedback!

Just one more question so we can have a resolution for this: is this bug still happening on the latest Nightly version (which is 71)?

Please let me know whenever you can

Thanks!

Best wishes,

Sebas

Comment 10

[Rob Schlüter]

I get the feeling that each time I supply information the only result is getting new questions.

Perhaps it's better to close this issue. I'm pretty sure it exists for a long time but the fact that it hasn't been reported earlier tells me that I'm probably the only one that thinks this is an error.

signing off,
rob

Comment 11

[Sebastian Padilla]

Hi Rob:

I've tried to reproduce this bug once again on Firefox Nightly (71.0a1 - 2019/12/09) but I wasn't able to.

Nontheless, I will add a component so a dev can check this out too and help us a little bit further.

Thanks!

Sebastian

Comment 12

[Emilio Cobos Álvarez [:emilio]]

This is expected. Doing so breaks websites, see the examples in https://github.com/w3c/csswg-drafts/issues/3739#issue-422418364.

Maybe we could special-case ex or ch to behave differently from ems, but that'd be adding more confusion here...

Comment 13

[Jonathan Kew [:jfkthame]]

Maybe we could special-case ex or ch to behave differently from ems

Yeah, I think that'd be more harmful than helpful overall.

It's debatable (in my mind, at least) whether our behavior here -- applying min-size to the used font size but not the computed size -- is the best approach or not.

I fear the reality is that plenty of sites have layouts that aren't robust enough to tolerate substantially zooming font size separately from overall page zoom. On top of that, applying a min-size clamp to small font sizes -- so that relative sizes of different elements as intended by the author are no longer maintained -- will break more pages. And whichever way it's handled, whether font-relative dimensions follow the "raw" zoomed size or the clamped size, there'll be cases that break.

On the whole, I think I find fantasai's comment reasonable; this would suggest that we should apply the min-size to computed sizes and font-based dimensions, not just the used size, although this would hurt the MSN example discussed in the chromium issue.

Emilio, how hard would it be to implement the alternative behavior and put it behind a pref, so that we could let people experiment with both approaches?

Comment 14

[Emilio Cobos Álvarez [:emilio]]

It's not only MSN fwiw, it's a ton of websites. Chrome messed up in a way that it was very easy to end up configuring a min font size of 6px and they got a gazillion reports about it.

See https://bugs.chromium.org/p/chromium/issues/detail?id=308862 and a bunch of the dupes for example, and a lot of others that are not there but I can dig if you want.

That being said, it's not hard to put behind a pref, it'd be a matter of tweaking other fields here, not only mFont.size.

Comment 15

[Jonathan Kew [:jfkthame]]

It looks like people complained because they're doing things like setting a really small font size on the root element (e.g. aiming for 1rem == 1px on a typical device), and then writing their layout in terms of those small rem units. (As one comment there says, "I suppose a workaround would be using larger rem units, similar to 16px or 1em. But the 1rem:1px ratio is so convenient...")

To me, that seems like somewhat of an abuse of the rem unit, and it's not surprising that if a minimum font size is then applied by the browser -- clamping rem to a larger size than the author expected -- such designs break. But if that kind of thing is at all widespread, maybe we're stuck with it.

Comment 16

[Emilio Cobos Álvarez [:emilio]]

Note that Chrome is switching to our behavior here: https://chromium-review.googlesource.com/c/chromium/src/+/1803281

It's unclear from that patch whether they special-case ex / ch, but from the looks of it they may be doing that.

Comment 17

[Jonathan Kew [:jfkthame]]

Interesting. I've commented there to raise the question of em vs ex/ch; curious to see what they think.

Comment 18

[BugBot [:suhaib / :marco]]

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Closing the bug as incomplete.

For more information, please visit auto_nag documentation.