1864445 - The "zoom text only" feature can break layouts if a site has a dependency on `rem` or `em` units working out to a precise pixel value (e.g. hessen.de). And this breaks sites by default if you pair it with the default-zoom feature

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect)

Description

[Raul Bucata]

From github: https://github.com/webcompat/web-bugs/issues/129492.

<!-- @browser: Firefox 115.0 -->
<!-- @ua_header: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0 -->
<!-- @reported_with: addon-reporter-firefox -->
<!-- @public_url: https://github.com/webcompat/web-bugs/issues/129492 -->

URL: https://hessen.de/presse/verwaltung-wird-buergernaeher-aufgestellt

Browser / Version: Firefox 115.0
Operating System: Windows 10
Tested Another Browser: Yes Edge

Problem type: Design is broken
Description: Items are overlapped
Steps to Reproduce:
Just visit the site, it's broken no matter if I use Firefox without uBlock Origin or deactivated tracking protection :-(.
<details>
<summary>View the screenshot</summary>
<img alt="Screenshot" src="https://webcompat.com/uploads/2023/11/b5fd62af-82ff-4c5c-8dfa-8f239ff1dfd8.jpg">
</details>

<details>
<summary>Browser Configuration</summary>
<ul>
<li>None</li>
</ul>
</details>

From webcompat.com with ❤️

Change performed by the Move to Bugzilla add-on.

Comment 1

[Raul Bucata]

The issue was reported via the webcompat.com reporter. Since the issue is related to the "Default zoom" and "Zoom text only" options of the browser, we have moved the issue. Please feel free to move the issue to the correct Product and Component.

Comment 2

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

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 3

[Daniel Holbert [:dholbert]]

STR here don't actually require default-zoom.

Simplified STR:
(1) In Firefox Preferences, check the "Zoom text only" checkbox.
(2) View the URL.
(3) Ctrl+ to zoom in one tick.

Diagnosing in devtools, it looks like this is an issue with a site that's doing its layout using a mix of pixel values (which don't scale with text i.e. font-size) and em/rem values (which do scale with font-size).

The site has an element whose width is established by max-width: 1520px, and it has a flex container that has flex-wrap:wrap:

  display: flex;
  flex-wrap: wrap;

And then inside of that flex container, they have two flex items:
(1) a container for the specially-posiitoned navbar on the left
(2) a container for the main content.

The first flex item's width is established by max-width: 37rem;.
The second flex item's width is established by max-width: 928px;

The site sets font-size: 16px; on the root element; so by default, the first flex item ends up being 37*16px = 592px wide. And the two flex items fit side-by-side, because 592px + 928px = 1520px which exactly the space that they've declared on the container.

However, if you zoom the text to 110%, then suddenly 1rem becomes greater than 16px, so the first flex item (whose size is specified in rem becomes wider, so the flex items suddenly don't fit side by side anymore. (In some cases a flex item will shrink, but not in this case, because the site zeroes out the flex-shrink value.)

So, the second flex item wraps to below the first, since it doesn't fit and flex-wrap:wrap tells it to wrap. And unfortunately that makes it get covered up, because the site has designed things such that the first flex item is actually just a zero-height container for a fixed-position navbar that stacks in the foreground. So, when the second flex item wraps "below" the first item, it's really just snapping to the left edge, underneath the fixed-position navbar.

So, that's how we end up with the layout that we do here.

tl;dr: the "zoom text only" feature can be a bit fragile in cases where site layouts have extremely precise dependencies on em/rem units working out to very precise pixel sizes. And this site is one such case.

Comment 4

[Daniel Holbert [:dholbert]]

I don't know for sure, but I imagine this might be fragile enough that it could be worth warning users against using "default zoom" in combination with "zoom text only".

With either feature enabled, sites should typically look reasonable by-default. But with both of them enabled, sites might look broken by-default and may have to manually zoom out in order to figure out what's going on and get to a functional layout.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Here's a reduced testcase that reproduces the issue as described in previous comment's STR and analysis of what's-going-wrong.

If you've got text-zoom enabled, you can see that the cyan-bordered element gets wider and wider as you zoom in (since its width is specified in terms of rem which scales with the text size); while the rest of the layout doesn't experience the same growth, so it gets displaced/covered up.

Comment 6

[Daniel Holbert [:dholbert]]

It looks like this UI was added as part of bug 1590485, so I'm pretty sure this issue would go back to that, in terms of being a user-exposed issue.

(I can reproduce this in older builds if I manually toggle the browser.zoom.full pref to false which is equivalent to the zoom-text-only checkbox. But I don't think we had user-facing UI for this at that point, so bug 1590485 is probably where this might start.)

Hence, adding dependency on bug 1590485.

Morgan, any thoughts on what we might do here & do you have cycles to take a look as follow-up to bug 1590485? I'm imagining we might extend the zoom about:preferences UI with some sort of warning alongside the "zoom text only" checkbox -- something like:

Warning: some websites may break when zoomed under a "zoom text only" configuration, if their layout is fine-tuned to depend on text sizing.

(We could also conceivably only show that if you check the checkbox and also set a non-100% default-zoom, since that's what would make such websites broken-by-default rather than broken-at-the-moment-that-you-zoom-them. And the broken-by-default situation is really the situation that we want to warn folks about, I think.)

Comment 7

[Morgan Reschenberg [:morgan]]

(In reply to Daniel Holbert [:dholbert] from comment #6)

It looks like this UI was added as part of bug 1590485, so I'm pretty sure this issue would go back to that, in terms of being a user-exposed issue.

(I can reproduce this in older builds if I manually toggle the browser.zoom.full pref to false which is equivalent to the zoom-text-only checkbox. But I don't think we had user-facing UI for this at that point, so bug 1590485 is probably where this might start.)

Hence, adding dependency on bug 1590485.

Morgan, any thoughts on what we might do here & do you have cycles to take a look as follow-up to bug 1590485? I'm imagining we might extend the zoom about:preferences UI with some sort of warning alongside the "zoom text only" checkbox -- something like:

Warning: some websites may break when zoomed under a "zoom text only" configuration, if their layout is fine-tuned to depend on text sizing.

(We could also conceivably only show that if you check the checkbox and also set a non-100% default-zoom, since that's what would make such websites broken-by-default rather than broken-at-the-moment-that-you-zoom-them. And the broken-by-default situation is really the situation that we want to warn folks about, I think.)

hello !
I think adding that warning is a great idea, text zoom has been janky for quite a while and I think it's worth advising users that it might not do exactly what it says. I'll take that on :) thanks for the flag

Comment 8

[Daniel Holbert [:dholbert]]

Thanks!

Comment 9

[Morgan Reschenberg [:morgan]]

Attachment: Bug 1864445: Add text zoom only warning r?dholbert

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0bb342554809
Add text zoom only warning r=dholbert,fluent-reviewers,desktop-theme-reviewers,dao,mconley,flod

Comment 11

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/0bb342554809