1838401 - Regression in text scaling - layouts breaking

Status: NEW

(Core :: Layout: Scrolling and Overflow, defect, P3)

Description

[jaroslaw.jarosik]

Steps to reproduce:

Set up systemwide "size" and "text size" to minimum
Leave in-browser scaling setting to auto
Visit one of listed websites

the issue happens also in 116, using manual scaling instead triggers the issue around the threshold of 75%, I reproduced the issue using a clear profile (app installed in Work Profile, had to use the manual scaling since the automatic doesn't work there)

Actual results:

• m.facebook.com - white margin on the right and false horizontal scroll
• purepc.pl - width of hero images shrunk when compared to earlier versions
• try replying to comment on purepc.pl - some content is clipped

Expected results:

Layouts should be rendered as before/without these issues

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jonalmeida, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Olivia Hall [:olivia]]

Thank you for the bug report!

I was able to reproduce issue on a Pixel 4a in Beta 115.0b8 and Nightly 116 - the results look similar to bug 1840879.

Release 114 was not impacted.

This bug STR use system scaling settings + Firefox scaling mirroring system settings and bug 1840879 uses Firefox scaling settings.

Both seem to have the same root cause, so I'm going to mark bug 1840879 as a duplicate of this bug.

Comment 4

[Olivia Hall [:olivia]]

Attachment: scaling-issue.png

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:hiro, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Hiroyuki Ikezoe (:hiro)]

Olivia, can you reproduce the issue on GeckoView example too? If so, please try "./mach mozregression -n gve -g 114" to identify the regressor. Thanks!

Comment 7

[Olivia Hall [:olivia]]

I can reproduce on GVE by changing float mFontSizeFactor = 1f; to float mFontSizeFactor = 2f; and visiting ca.yahoo.com and slightly pulling the frame right to left. (Not entirely sure if that is a valid value, but it visually looks correct.) I had trouble with mozregression, because it doesn't look like there is a pref or UI I can set outside of that code change for GVE.

If I revert bug 1831136 locally and change final Pref<Integer> mFontSizeFactor = new Pref<>("font.size.systemFontScale", 100); to final Pref<Integer> mFontSizeFactor = new Pref<>("font.size.systemFontScale", 200);, then it seems to return to the expected behavior. With that reverted and set to 200, when visiting ca.yahoo.com, the text is zoomed and slightly pulling the frame right to left does not reproduce the issue. I'll tentatively connect to bug 1831136.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1831136

:emilio, since you are the author of the regressor, bug 1831136, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

That bug changed OS text behavior to match behavior of OS text zoom in other platforms (so, full zoom). I don't see the frame right to left, but if you zoom 200% it's expected that yahoo is cropped.

I guess the android behavior before that patch was the same as browser.display.os-zoom-behavior = 2. So we could switch that back if needed. But the new behavior is a progression on other sites (specially with bigger fonts).

Comment 10

[jaroslaw.jarosik]

if I can provide more feedback: the previous behavior was what I considered perfect, and certainly better than Blink based browsers did, but as I said I am using reduced sizes both for text and for "screen" in Android settings and it's entirely possible the old code misbehaves with these increased or other cases

taking the purepc.pl homepage as an example, on Fennec before and on Fenix up until this change text was properly reduced in size and the hero images spanned the whole width, on Vivaldi since they started scaling text down the text size is basically the same but hero images are taking probably 90% of the width, on Lemur text is again fine, but hero images are taking probably around 70% of the width, browsers with less changes from the upstream (so Chrome, Brave and so on) don't even reduce the size at all, but images are again full width

and obviously parts of the site being cut off outside of the viewport and being inaccessible is a much more important issue than the slight reduction of the width of these images, but it seems these are symptoms of the same change, so I hope my explanation will be helpful

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox116 (beta) and tracked for firefox117 (nightly). We have limited time to fix this, the soft freeze is in 2 days. However, the bug still isn't assigned.

:fgriffith, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 12

[Frank Griffith Jr]

Emilio, do you have this on your radar or do you need input from Botond on this issue? Also, what severity should this have?

Comment 13

[Emilio Cobos Álvarez (:emilio)]

I can reproduce the behavior change, and as I said is intended to match how this feature works on desktop, and generally to get more consistent layout (since sites usually aren't coded with the expectation of text-only zoom).

We could switch browser.display.os-zoom-behavior on Android only I suppose, but I'd like to understand what's going on above, because I can't reproduce the inaccessible content described above, e.g. in purepc.cl on my device. I might be missing something? Maybe something got fixed in the meantime that makes this not reproducible on Nightly?

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Attachment: Scaling of ca.yahoo.com on Emilio's nightly.

This is with non-auto text scaling, but with the lowest scaling I could get in the Fenix settings.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Attachment: Screenshot on Emilio's nightly with system font scaling, and as little scaling as the OS lets me

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Olivia what do I need to do to repro comment 4 on Nightly?

Comment 17

[Emilio Cobos Álvarez (:emilio)]

Can you reproduce the same issue without the automatic sizing, but with the Firefox setting set to the minimum (50%)? Just to try to reduce this, since apparently my device doesn't let me scale down as much as yours.

Comment 18

[Emilio Cobos Álvarez (:emilio)]

comment 4 looks some sort of graphics glitch but I can't reproduce anything like that locally.

Comment 19

[Olivia Hall [:olivia]]

Olivia what do I need to do to repro comment 4 on Nightly?

Thanks for taking a look!

On a Pixel 4a on Android 13, I reproduced by:
a.) Set the accessibility settings to 200% using Firefox settings
or a.) or set to mirror OS and increase to the largest text size in the OS settings
c.) Visit ca.yahoo.com and slightly grab a blank spot and pull right to left

Comment 20

[Emilio Cobos Álvarez (:emilio)]

Ah, so that's a completely different set-up as comment 0, which is about reducing scale.

Comment 21

[Emilio Cobos Álvarez (:emilio)]

Attachment: Emilio's release screenshot for comment 19

Okay, I can repro that (I couldn't on nightly because I use an ad blocker) but that's because there's an element overflowing the viewport which you otherwise could not see.

You can repro that even on regular websites, and even on DevTools RDM if there's an absolutely-positioned element larger than the viewport.

Comment 22

[Emilio Cobos Álvarez (:emilio)]

try replying to comment on purepc.pl - some content is clipped

I tried this and I can't reproduce. The border is occasionally missing only if you zoom out, but that happens without scaling (that's bug 1258112 for example).

Comment 23

[Dianna Smith [:diannaS]]

any action here for 116 (e.g. a backout ) ? there is an rc2 re-spin building tomorrow.

Comment 24

[Emilio Cobos Álvarez (:emilio)]

I don't think we should back out. We could restore the behavior by flipping a pref, but I also don't think that's desirable. The new behavior is a better in most cases.

Comment 25

[jaroslaw.jarosik]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #17)

Can you reproduce the same issue without the automatic sizing, but with the Firefox setting set to the minimum (50%)? Just to try to reduce this, since apparently my device doesn't let me scale down as much as yours.

yes, while trying to reproduce on a new profile which isn't really feasible on Android I used Work Profile to get a new one and there automatic scaling doesn't work at all so I had to use manual and the result is exactly the same, I also mentioned this in the original report

personally I experienced 0 websites where there was any noticeable change that wouldn't be breaking, everything besides these few broken websites looks exactly the same

I know there was a reason for this change, but I believe in UX over correctness

Comment 26

[Botond Ballo [:botond]]

(I don't have much to add -- I'm not very familiar with the background of the regressing change or the code it's touching, and I'm happy to defer to Emilio's judgment on the best way forward.)

Comment 27

[Daniel Holbert [:dholbert]]

[Calling this wontfix for 116, since that release is shipping imminently and any fix here wouldn't merit the risk of a chemspill or dot release for 116.]

Comment 28

[Botond Ballo [:botond]]

I'm going to tentatively mark this as an S2 to get it off the triage dashboard (but Emilio please feel free to alter the severity as you think is appropriate).

Comment 29

[Emilio Cobos Álvarez (:emilio)]

Can you screenshot the clipped content mentioned in comment 0? I don't see that, and that's the concerning thing on my end. The layout change in purepc.pl seems expected.

Comment 30

[jaroslaw.jarosik]

Attachment: Screenshot_20230801-144737_Firefox_Beta.jpg

Comment 31

[jaroslaw.jarosik]

Attachment: Screenshot_20230801-144710_Firefox_Beta.jpg

Comment 32

[Emilio Cobos Álvarez (:emilio)]

Thanks! I can repro that at 75% scaling, but not at 50% scaling somehow.

Comment 33

[Emilio Cobos Álvarez (:emilio)]

Attachment: Test-case for one of the issues.

Somehow reducing zoom in some cases can drastically increase the size of a <textarea cols=""> element. That's causing the element to become too big.

This happens in desktop as well.

Still it shouldn't cause overflow tho, I haven't fully debugged what's going on.

Comment 34

[Emilio Cobos Álvarez (:emilio)]

Attachment: Reduced test-case for the clipped content.

Ok, so the main cause of the extra overflow in that page is that <textarea cols=""> sizing weirdness. This is a page that reproduces the same kind of overflow on desktop.

The right way to fix it is allowing flex items of .thecontent to shrink, so something like:

.thecontent > * {
  min-width: 0;
}

in purepc.pl's css would do.

So in so far there's something to fix here it's that inconsistent textarea sizing issue described above. Will file a dependent bug on that. But Chrome also seems to suffer from a similar thing.

Comment 35

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1831136

Comment 36

[BugBot [:suhaib / :marco/ :calixte]]

This is a reminder regarding comment #11!

The bug is marked as tracked for firefox117 (beta). We have limited time to fix this, the soft freeze is in 13 days. However, the bug still isn't assigned and has low priority.

Comment 37

[BugBot [:suhaib / :marco/ :calixte]]

This is a reminder regarding comment #11!

The bug is marked as tracked for firefox117 (beta). We have limited time to fix this, the soft freeze is in 10 days. However, the bug still isn't assigned and has low priority.

Comment 38

[Ryan VanderMeulen [:RyanVM]]

We discussed this in regression triage today, and it seems like we need a Product decision here about whether we should take a short-term patch setting the browser.display.os-zoom-behavior=2 pref to revert to the previous behavior or put this bug into backlog for a longer-term refactoring. But at the end of the day, we'd be trading one set of layout bugs for another, so it isn't necessarily clear which option is the better of the two.

Comment 39

[Emilio Cobos Álvarez (:emilio)]

Yeah, so there's a whole set of things that we should consider about text scaling. I commented with some other questions in bug 1845917 comment 5, and then there's the whole font inflation shenanigans in bug 1828327.

Comment 40

[Chris Peterson [:cpeterson]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #38)

We discussed this in regression triage today, and it seems like we need a Product decision here about whether we should take a short-term patch setting the browser.display.os-zoom-behavior=2 pref to revert to the previous behavior or put this bug into backlog for a longer-term refactoring. But at the end of the day, we'd be trading one set of layout bugs for another, so it isn't necessarily clear which option is the better of the two.

I'll pass this question along to the Android team.

How does Firefox's behavior (currently and with os-zoom-behavior=2) compare to Chrome and Safari?

Comment 41

[Emilio Cobos Álvarez (:emilio)]

Not sure Safari, but Chrome doesn't scale following the platform settings by default (they have a different zoom in the accessibility settings). They do something weird where they don't scale all of the text, only some.

Comment 42

[jaroslaw.jarosik]

Android "Chromium" in general doesn't scale the text below 100% no matter the position of the slider in accessibility settings (unless it changed sometime recently)
Vivaldi and Lemur scales automatically and I'm pretty sure there were one or two with a working slider
both are producing results similar to the current Fenix: images on the main page of purepc.pl aren't edge to edge, login form is cut off on the left, though in a slightly different way than on Fenix, on mobile Facebook the white bar on the right is much bigger than on Fenix and horizontal scrollbar appears even though you can't actually scroll it