Firefox doens't react properly to scale changes any more
Categories
(Core :: Graphics, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | affected |
People
(Reporter: kubrick, Unassigned)
Details
Attachments
(1 file)
|
403.82 KB,
image/png
|
Details |
Since last week, on Gnome 3.34.1, with FF Nightly, on my multi-dpi setup, FF stopped reacting to changes of resolution/scale properly, like when dragging from one screen to the next or switching from docked (100% scale screens) to laptop display (HiDPI, 200%). See attached screenshot of the FF windows when resuming from sleep.
Tested on Gnome Wayland and X11. Linux 5.3, Iris Graphics 540, arch linux.
Restarting FF fixes the problem.
Updated•6 years ago
|
Comment 1•6 years ago
|
||
I have NOT managed to reproduce this in a Ubuntu 18 desktop with 1 HDPI monitor with scaling set to 2 and one smaller monitor with scaling set to 1 by moving a window from on monitor to the other. I will now assume that I may have been missing some details in the reproduction of this bug or it is specific to the OS you reported on and we don't have one.
I have to ask you to help us regress this issue. Will you help us?
These are steps you need to use in order to correctly find out the commit that made the issue appear:
- You have to determine a build that reproduces the issue. That is yesterday's buit if you reproduced it on the latest build before reporting it. Otherwise, it's a build that you remember to hade reproduced it on. (Nightly v72.0a1 from 2019-10-21)
- Then you should find one that does NOT reproduce it. It also appears that you've already done that: A build before last week. (Nightly v71.0a1 from 2019-10-05)
- You need to install mozregression on your system.
a. Open terminal
b. Run command: "sudo apt-get install python-pip"
c. Run Command: "sudo pip2 install -U mozregression"
After running these 2 comands, mozregression should be installed and you can check that by running command "mozregression --v" and see it's version. It it is not installed, this command will be invalid and you will need to throubleshoot the instalation of "pip" and "mozregression". - You will use mozregression app to "bisect" builds that reproduce the issue by builds that do not reproduce it in search of the one build/changeset that introduced the issue, in the first place:
a. Open terminal.
b. If the good vs bad build dates above are correct, then you will run the following command to start a bisection (regression test) of your issue:
"mozregression --good 2019-10-05 --bad 2019-10-21"
c. Builds will open one-by-one, you will need to test each one of them and see whether the issue reproduces. If it reproduces, then you need to input "bad" string in the terminal window and tap ENTER and if not, you need to input "good" string and tap ENTER.
d. When bisection is done, you will have the information in the terminal window; bisection may also fail due to not enough builds, but the logs can always be useful. - Copy the logs in a text file and attach it to this bug.
If there is still information you need regarding the regression process, please request information from me.
Thank you for your contribution!
Comment 2•6 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
Updated•6 years ago
|
Updated•6 years ago
|
| Reporter | ||
Comment 3•6 years ago
|
||
Sorry, I can only reproduce it by connecting and disconnecting a monitor, which makes it time consuming to debug. I will try to do it at some point...
| Reporter | ||
Comment 4•5 years ago
|
||
This has magically been fixed with gnome 3.36
Description
•