Open Bug 1925284 Opened 1 year ago Updated 3 months ago

OS custom DPI: Browser window height is shorter on window open (Ubuntu Xfce)

Categories

(Core :: Widget: Gtk, defect, P3)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 131
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: sam.xubuntu, Unassigned, NeedInfo)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0

Steps to reproduce:

Conditions:

  • Firefox since version 131.0 (or 131.0.2?), which is when something about the DPI has been changed, which is very likely related to the problem. In fact, I noticed the content of any site appeared more zoomed in after upgrading to this version (which is fine, that's not the issue but, again, whatever has been changed might be related to the bug that I'm reporting here).
  • Ubuntu 22.04.5 LTS
  • Xfce 4.16
  • Custom Xfce DPI setting is set to a custom value (more than "100").

Steps:

  • Open Firefox.
    or:
  • Open a new Firefox window.

Actual results:

Firefox window height is shorter, so I can see about 20 pixels of my desktop background. Manually fixing it and restarting the browser has no effect, the correct height is not remembered.

Expected results:

I expected Firefox to keep the same windows height it had after the last use, as it was correctly happening in previous Firefox versions.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Still present in 133.0.3.

Can you use mozregression to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Flags: needinfo?(sam.xubuntu)
Priority: -- → P3

Can you use mozregression to find broken commit?
No.
My OP provides enough details anyway, it's when DPI-related changes have been done around v.131.0.

Flags: needinfo?(sam.xubuntu)

Without mozregression step we can't proceed here, sorry.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX

Without mozregression step we can't proceed here, sorry.

2:33.91 INFO: No more integration revisions, bisection finished. 2:33.91 INFO: Last good revision: c55deb4d22cde9f2915ec9a8d4bf57ea41913ff5 2:33.91 INFO: First bad revision: 61268a890b3c86ab4f5cfd7c6e1e3d14cc68f0b6 2:33.91 INFO: Pushlog: https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=c55deb4d22cde9f2915ec9a8d4bf57ea41913ff5&tochange=61268a890b3c86ab4f5cfd7c6e1e3d14cc68f0b6

Flags: needinfo?(stransky)
Flags: needinfo?(stransky)

Thanks, unfortunately the pushlog size is too big. I don't see anything obvious in the regression range.

Can you please remove the "resolved wontfix"? This is an annoying bug that requires the user to adjust the window height manually every time a new window is open.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #7)

Thanks, unfortunately the pushlog size is too big.

Did I use mozregression wrong, or it just happens that the affected version has a lot of commits?
In that case, can I help you with anything else?

By the way, please see if one of these could be the culprit:
https://hg.mozilla.org/releases/mozilla-release/rev/7ee9d19b16598c0f513d54c9ef323129e4735eee
https://hg.mozilla.org/releases/mozilla-release/rev/db67a891f2902f3991bda61f86601e46fb437017

Flags: needinfo?(stransky)
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(stransky)
Resolution: WONTFIX → ---

(In reply to SamXubuntu from comment #8)

Can you please remove the "resolved wontfix"? This is an annoying bug that requires the user to adjust the window height manually every time a new window is open.

Done.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #7)

Thanks, unfortunately the pushlog size is too big.

Did I use mozregression wrong, or it just happens that the affected version has a lot of commits?
In that case, can I help you with anything else?

You used it correctly but there are too many changes in the range and particular builds are not preserved.

By the way, please see if one of these could be the culprit:
https://hg.mozilla.org/releases/mozilla-release/rev/7ee9d19b16598c0f513d54c9ef323129e4735eee
https://hg.mozilla.org/releases/mozilla-release/rev/db67a891f2902f3991bda61f86601e46fb437017

Yes, looks likely. You can try to back them out and build latest trunk without it, there's a how-to:
https://mastransky.wordpress.com/2023/07/04/no-one-fights-alone-a-guide-to-your-first-firefox-patch-on-linux/

(In reply to Martin Stránský [:stransky] (ni? me) from comment #10)

https://hg.mozilla.org/releases/mozilla-release/rev/7ee9d19b16598c0f513d54c9ef323129e4735eee

Unlikely, it is android-specific, effectively.

https://hg.mozilla.org/releases/mozilla-release/rev/db67a891f2902f3991bda61f86601e46fb437017

Also somewhat unlikely, this is RFP (resistFingerPrinting) specific.

Pretty sure the culprit is likely to be bug 1211547.

I'm curious, does this work on Nightly? This looks almost the same as bug 1951296, which I fixed just now :)

Flags: needinfo?(emilio) → needinfo?(sam.xubuntu)

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

I'm curious, does this work on Nightly? This looks almost the same as bug 1951296, which I fixed just now :)

It works only when starting Firefox: however, opening a new Firefox window via the menu still presents the bug.

Additional info: please note that the bug happens in both of these cases: with the Xfce panel (horizontal) at the bottom of the screen, and with the Xfce panel (horizontal) at the top of the screen.

  • With the panel at the bottom: the new window has a short height, and so there is an empty space of ~ 20 pixels at the bottom (it doesn't touch the bottom panel).
  • With the panel at the top: the window moves down and the height is then adjusted to fit the bottom, resulting however in ~ 20 pixels of empty space at the top (it doesn't touch the top panel).
Flags: needinfo?(sam.xubuntu)

So, 6 months of nothing?
I guess when it comes do DPI issues it's a bit complicated because not a lot of users change that.
But in every OS that I use I always increase it, otherwise I strain my eyes.
I've tried in VirtualBox too, and I was able to reproduce the issue with the latest Xubuntu LTS.

The userbase here would be those that:

  • use Firefox
  • in Xfce
  • and they change the DPI settings

I guess it's a small set of users, and so I'm probably the only one reporting this.
But it's super annoying having to resize the window every time, I can tell you.

Let me know if there are any other tests that I could run, or if any of you guys can reproduce the bug e.g. in a virtual machine.

Discard everything I've said, this happens on Windows too.
Try on Windows 11 with a DPI of "120", same steps.

Correction: I've tried again on Windows, and it was probably the issue about the 1-pixel / 2-pixel gap around windows, which is unrelated and it's not a Firefox issue. The gap in Xfce, instead, is way bigger and I can still reproduce it consistently.

This is still open. In the meanwhile I'm asking for help here:
https://support.mozilla.org/en-US/questions/1533658

Additional info

The bug doesn't happen with a Xfce DPI setting of exactly 120. Any other value is currently giving me the bug.

I'll try to repro again

Flags: needinfo?(emilio)

So I tried with a variety of DPI settings (As in Settings Manager > Appearance > Fonts > Custom DPI) and I can't repro this.

This is what I'm trying to do, with and without the titlebar checkbox on:

  • Open a Firefox window.
  • Size it to something small, so that XFCE opens windows such that they overlap with each other.
  • Open a new window via Menu > New Window (or Ctrl + N)
  • Check the size with the previously-opened window.

They're ~always the same, except some few cases if you open windows very fast where the new window is slightly bigger. That's unfortunately not (quite) our fault, because it seems XFCE sends us a configure event, but then the property-notify for net-frame-extents much later. So when we try to get the restored size we return a slightly bigger size than we would otherwise...

Am I doing something wrong? Could you attach your about:support and maybe more concrete steps to reproduce?

Flags: needinfo?(emilio) → needinfo?(sam.xubuntu)
Depends on: 1987267

Size it to something small, so that XFCE opens windows such that they overlap with each other.

I'm puzzled to see that I've missed to specify that one year ago, but the window height must cover the whole available space (except for the Xfce panel that may be present). To do that, you need to resize the window until the WM automatically "snap-resizes" it to cover the whole screen's height.

So the steps would be:

  • DPI setting in Xfce set to anything but 120. 110 is a good example.
  • Open Firefox. Resize the window's height until it covers the whole screen height (or the whole screen minus the top or bottom panel height)
  • Open a new Firefox window.
  • Notice the gap above or below the window (the window height is shorter than the previous window).
Flags: needinfo?(sam.xubuntu)

(and of course DPI setting greater than 100: greater than the default)

Despite me mentioning the Xfce's panels, please note that the gap size (how much the Firefox window's height is off) doesn't seem related to the height value of the existing Xfce panel: the gap size is only related to the DPI value.

Additional info: both width and height are affected

Since it turns out that the window being at full available desktop height is required for the bug to happen, I've just tested the same exact steps but by resizing the window's width instead, and the exact same bug happens with the window's width: opening a new window presents a gap on the right.

(In reply to SamXubuntu from comment #19)

(and of course DPI setting greater than 100: greater than the default)

The default is 96 fwiw :)

But ok, that explains the confusion, and also why we don't have many more reports of the same thing...

Flags: needinfo?(emilio)

I always make the browser take all the available height, in the OP I probably didn't think to mention it.

Are you at least able to reproduce the issue now, with the currently available info?

You need to log in before you can comment on or make changes to this bug.