1948638 - Blank space between top-toolbar and site content (after dynamic change to device DPI, via adjustment to "smallest width" Android developer option)

Status: NEW

(Firefox for Android :: Tabs, defect)

Description

[Calin Tanase]

Environment:
Operating system: Android 14 - Samsung Dex
Firefox version: Firefox Mobile [phone]

Preconditions:

• Change the DPI/smallest width in the phone settings, set it to a high number compared with the default

Steps to reproduce:

1. Go to https://duckduckgo.com/?q=gfs
2. Observe the header.

Expected Behavior:
It is displayed correctly.

Actual Behavior:
There's a gray area/bar displayed above the header.

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly
• Does not reproduce in firefox-release, beta and chrome

Created from https://github.com/webcompat/web-bugs/issues/148252

Comment 1

[Calin Tanase]

Attachment: behavior FF vs Chrome.mp4

Comment 2

[Jaefferson Nascimento]

I've seen the bug in Firefox versions 135 (Stable version), 136 (Beta version) and 137 (Nightly version). This bug occurs whenever I use Firefox on a secondary screen. I've noticed that the bug only occurs if the address bar location is at the top of the screen.

Comment 3

[Jaefferson Nascimento]

In addition to the gray bar, the site does not appear completely, part of the site is missing.

Comment 4

[Jaefferson Nascimento]

Attachment: Firefox on Samsung_Dex.jpg

Comment 5

[Daniel Holbert [:dholbert]]

So, a few observations:
(1) This is not specific to any one site. I can reproduce it with a trivial mostly-blank page, like https://example.org or even data:text/html,hi. Hence, removing duckduckgo from the URL and summary to avoid an implication that this specifically affects that one site (and migrating to be a general Fenix bug as noted below).

(2) Quoting comment 2: "I've noticed that the bug only occurs if the address bar location is at the top of the screen." -- I'm seeing this as well. (Note that you might not be able to move the toolbar after applying a higher DPI, because that toolbar top/bottom option in "Customize" disappears from Firefox settings for me, but it comes back and is configurable when I'm at my device's regular DPI.)

(3) The issue goes away if I force-quit Firefox. Specifically -- if I recreate the screencast shown in comment 1, and then I long-press the Firefox icon on the desktop and choose the (i) info-button and tap "Force Stop", and then re-launch Firefox, then it comes back with no such bar. So this isn't a persistent bug that affects Firefox forever when run under such a configuration; it's just triggered by dynamic DPI changes, I think. (Maybe that means it's also triggered when external displays are connected, per comment 2.)

(4) It looks like this is probably a bug with how Fenix's app layout -- possibly it's using a stale value for how tall the toolbar is, or it's getting confused about toolbar-height when toggling back and forth between mobile vs. tablet-style toolbars? But in any case, it seems like this ends up causing Fenix to place the surface-to-which-we-can-render-web-content too far down.

--> Reclassifying to Fenix since this seems like a bug with the Fenix app's own layout (and possibly [?] with accounting for top-toolbar height in the presence of dynamic DPI changes).

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Calin Tanase from comment #0)

• Does not reproduce in firefox-release, beta

This^ doesn't match reality for me. I can reproduce in Firefox release 135.0.1, and even in Nightly 2024-09-01 (131.0a1). (Note that per comment 2, you do need to have the toolbar at the top of the screen in order to reproduce, I think, so that might be a reason that this appears to not repro on some builds/configurations.)

This might still be a regression, but perhaps it's an older one than how we've got it flagged right now.

Comment 7

[Daniel Holbert [:dholbert]]

I used mozregression to bisect this a bit and got:
first bad: 2024-07-10 f6ae1b587092
last good: 2024-07-09 1316cd6c71f8

Comparing those builds, the relevant change (which I can see from just launching them) was the navbar becoming default-enabled. And if I disable the navbar in the Secret Settings menu in the first-bad build, then it instead starts giving me "good" results. So at that point in our history, this regressed due to the introduction of the navbar.

That's not the full story, though, because in latest Nightly 2025-02-28, I still get "bad" results even if I disable the navbar (and per previous comment, Firefox release 135.0.1 gives me "bad" results despite not having a navbar). So this may have initially regressed with the navbar being enabled, but it broadened to not require that at some point.

Comment 8

[Daniel Holbert [:dholbert]]

I ran mozregression again, manually disabling the navbar in each trial before testing, and I got this later pushlog for when things went bad in a navbar-disabled configuration:

first bad 2024-09-24 adf3c6ac684d
last good 2024-09-23 f4f1159d250a

That maps to this regression-range pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f4f1159d250a&tochange=adf3c6ac684d

My best guess at a regressor in there would be this:
https://hg.mozilla.org/mozilla-central/rev/1d19595d97911963089b577a06763e1823e9f487
mike a. — Bug 1918757 - Apply height params passed to initializeEngineView within the function r=android-reviewers,petru

(Or perhaps one of these: https://hg.mozilla.org/mozilla-central/rev/0acd31397ef7f098a63f13236585391e2fc5d36a
rahulsainani — Bug 1920514 - Update tab strip item ui properties r=android-reviewers,calu
https://hg.mozilla.org/mozilla-central/rev/40833555896a46ed8b10389fac977df5678ab964
mike a. — Bug 1906795 – Implement new landscape design for custom tabs r=android-reviewers,skhan,twhite
)

But bug 1918757 looks particularly relevant since it seems to be about the sizing of the area that we give to the rendering engine and how it relates to the toolbar top/bottom placement (which is a key factor in reproducing this bug per comment 2), and also it looks like the commit is removing a dynamic-lookup of the current pixel size (resources.getDimensionPixelSize(R.dimen.browser_toolbar_height) etc) and replacing it with a use of some cached sizes maybe (OldToolbarPosition.TOP -> topToolbarHeight) which seems like the sort of thing that could introduce a bug like this, when the device DPI gets changed out from under us dynamically.

Comment 9

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

:mavduevskiy, since you are the author of the regressor, bug 1918757, could you take a look?

For more information, please visit BugBot documentation.

Comment 10

[Dennis Schubert [:denschub][Vacation, back Sep. 22]]

dholbert unset the URL in comment 5 for very valid reasons - but this shows up in our "site report without a URL" tracking queue, so I'll add the URL back in. This is affecting a lot of sites, but having DDG as one high ranking site is good enouhg.

Comment 11

[Daniel Holbert [:dholbert]]

followup to comment 10, per slack discussion just now: the only reason this was showing up in that webcompat tracking-queue because we still had some webcompat metadata here -- but that doesn't make sense, since this is really just Firefox UI breakage (though that's admittedly non-obvious, since it's Firefox UI that's adjacent to the web content area).

Let's just remove the webcompat metadata (and remove the URL again since this isn't specific to any site) so as not to have it confusing the webcompat tracking/triage process.

Comment 12

[Roger Yang [:royang]]

I can reproduce this. but this only happens when tab strip is triggered. (Larger size changes the toolbar to tab strip). Moving this to Tabs as a tabs strip investigation. I don't think we can handle dynamically enabling tab strip.