1757410 - Scroll thumb disappears if Firefox is moved between screens of different resolutions

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[Bogdan Maris, Desktop Test Engineering]

Affected versions

• Firefox 92.0a1
• Firefox 97.0.1
• Firefox 98.0b9
• Latest Nightly 99.0a1

Affected platforms

• MacOS 11.6

Steps to reproduce

1. Open Firefox on MacBook screen
2. Visit a website with scroll, best reproducible on Wikipedia.org homepage
3. Scroll inside the webpage
4. Move Firefox to the external screen
5. Scroll inside Firefox
6. Refresh the website
7. Move Firefox back to MacBook screen
8. Scroll inside Firefox

Expected result

• Step 5 and step 8 - Scrollbar is visible and the page can be scrolled. Scroll elevator has the same height on both screens.

Actual result

• Step 5 - Scrollbar is invisible though the page can be scrolled. Scroll elevator is not visible and can`t be clicked.
• Step 8 - Scrollbar is visible but the scroll elevator has a significant shorter height and does not move through the entire height of the scrollbar.

Regression range

• First bad: 295399ab
• Last good: b920e6d7
• Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b920e6d71a33db0359f6b4852586dab72ef29281&tochange=295399ab06a803980dcf13442689369572a21c37
• Potential regressor: Bug 1718012 - Zoom out and triggering full screen will break DOM rendering

Additional notes

• MacBook Pro with 1792x1120 resolution, one or two external screens with 1920x1080 resolution.
• I am not sure if this is also reproducible using windows machine, I don't have one at my disposal.

Comment 1

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

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

Comment 2

[Hiroyuki Ikezoe (:hiro)]

Bogdan, I'd assume the browser window size wasn't changed but the DPI for each screen is different, right? I'd guess the macbook pro is HiDPI mode, rather the external ones are normal DPI.

Comment 3

[Bogdan Maris, Desktop Test Engineering]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #2)

Bogdan, I'd assume the browser window size wasn't changed but the DPI for each screen is different, right? I'd guess the macbook pro is HiDPI mode, rather the external ones are normal DPI.

Correct, the browser window did not change after moving from one screen to another. The Mac I'm using is MacBook Pro (16-inch, 2019); CPU: 2,3 GHz 8-Core Intel Core i9; GPU: Intel UHD Graphics 630 1536 MB with the display set to Default scale (1792x1120 resolution) and the external monitors are set to Default scale as well, FullHD max (1920x1080 resolution).

Comment 4

[Hiroyuki Ikezoe (:hiro)]

Thanks!

I suppose when the DPI is changed, nsPresContext::AppUnitsPerDevPixelChanged ensures at least one reflow, but there seems a race condition it doesn't work as expected.

Comment 5

[Timothy Nikkel (:tnikkel)]

For me the scroll thumb completely disappears and does not reappear even after scrolling the page.

Comment 6

[Donal Meehan [:dmeehan]]

:hiro is this something that can be fixed?

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Yes, I believe so.

In bug 1718012 I moved mMobileViewportManager->UpdateSizesBeforeReflow() call into PresShell::SimpleResizeReflow(), but now I think it should be moved into PresShell::ResizeReflowIgnoreOverride, SimpleResizeReflow is a special case in ResizeReflowIgnoreOverride. With the change, I think mobile viewport stuff works for the DPI changes case. But I don't have any setup to test it locally.

Comment 8

[Timothy Nikkel (:tnikkel)]

I can look into this.

Comment 9

[Hiroyuki Ikezoe (:hiro)]

This is probably Mac specific (as the bug reporter filed originally).

Today I tested my Linux box with Wayland where I can setup different scale on multiple monitors. I have been using 4K monitor which can be divided as two monitors side-by-side. On the GNOME settings I changed one of the monitors scale to 200% and the other is 100%, but I don't see any issues while moving Firefox window in between the monitors.

Comment 10

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1757410 - Ensure MobileViewportManager::UpdateSizesBeforeReflow gets called with up-to-date app-units-per-dev-pixel and CV bounds in UIResolutionChangedInternal. r?emilio

The change does trigger reflows, it doesn't change the root frame size, but it
needs to change MobileViewportManager metrics, specifically mDisplaySize.

The reason why we invoke UpdateSizesBeforeReflow in
FlushPendingMediaFeatureValuesChanged rather than UIResolutionChangedInternal
is UIResolutionChangedInternal gets called just before changing the widget size
and position in BrowserChild::RecvUIResolutionChanged so that
MobileViewportManager will pick the old size if it's used in
UIResolutionChangedInternal.

Comment 11

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1757410 - Add a test case that MobileViewportManager is properly updated when browser window moves from a HiDPI monitor to normal one. r?tnikkel

Unfortunately this test doesn't run as expected on our CI since macs on our CI
are running normal DPI mode.

I tested this test works properly on my macbook, it fails without the fix in the
previous commit and it passes with the fix.

Depends on D153687

Comment 12

[Hiroyuki Ikezoe (:hiro)]

I am going to land D153687 without tests (D153688).

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3459b021f7a5
Ensure MobileViewportManager::UpdateSizesBeforeReflow gets called with up-to-date app-units-per-dev-pixel and CV bounds in UIResolutionChangedInternal. r=emilio

Comment 14

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/3459b021f7a5

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Can we move the tests to a new bug so we can close this out as resolved?

Comment 16

[Phabricator Automation]

Comment on attachment 9288405 [details]
Bug 1757410 - Add a test case that MobileViewportManager is properly updated when browser window moves from a HiDPI monitor to normal one. r?tnikkel

Revision D153688 was moved to bug 1786668. Setting attachment 9288405 [details] to obsolete.

Comment 17

[Hiroyuki Ikezoe (:hiro)]

Done!

Comment 18

[Bogdan Maris, Desktop Test Engineering]

I can confirm that the issue here is fixed for me on macOS 11.6 using the latest Nightly 106.0a1 and Firefox 105.0b8.