Open Bug 851930 Opened 12 years ago Updated 2 years ago

Firefox doesn't maximize properly

Categories

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

19 Branch
x86_64
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: inittab, Unassigned)

Details

(Whiteboard: tpi:+)

Attachments

(2 files)

Attached image Firefox Maximized
When I hit the maximize button in Motif Window Manager (from OpenMotif 2.3.3 - upstream debian), Firefox x64 19.0.2 maximizes much larger than the screen itself (see screenshot). I believe this issue was introduced in 16, 17, or 18. It's been a problem for a while now and as a result I generally end up using Chrome.
Can you try to find the regression range ? We have this tool that helps with finding it : http://mozilla.github.com/mozregression/
Component: General → Widget: Gtk
Product: Firefox → Core
Last good nightly: 2012-07-31 First bad nightly: 2012-08-01 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9d2a7a8ca1c7&tochange=582d4c67b3a7
I suspect bug 357725 Could you try a nightly build ? This could be fixed already by e.g. bug 813997
It's still an issue in 22.0a1 (2013-03-17).
Do you have multiple monitors and/or virtual desktops?
Nope, it's running a single monitor and MWM doesn't support virtual desktops. I've confirmed the behavior on the virtual machine I use at work as well as my personal laptop and desktop, all of which run MWM. The Debian package for OpenMotif MWM is motif-clients, but I suspect you could reproduce with the upstream source from openmotif.org. This may even be an issue under CDE (which does support virtual desktops) -- not certain.
I've downgraded to 17.0a1 (2012-07-31) and disabled Nightly automatic updates to work around the issue. I may end up exposed to a host of bugs but it's either that or using Chrome exclusively at this point. Let me know if there's anything else I can do to help! Thanks!
I downloaded a full copy of changeset 9d2a7a8ca1c7 and 582d4c67b3a7 and made a diff between the two source code trees. This may have been introduced by the introduction of nsWindow::SetSizeConstraints and associated modifications to nsWindow::Resize in widget/gtk2/nsWindow.cpp. There are also several modifications to layout/xul/base/src/nsResizerFrame.cpp and layout/generic/nsContainerFrame.cpp that concern me, particularly the following: + + if (!aRC) + return; + + nsBoxLayoutState aState(aPresContext, aRC); + nsSize minSize = rootFrame->GetMinSize(aState); + nsSize maxSize = rootFrame->GetMaxSize(aState); + + SetSizeConstraints(aPresContext, windowWidget, minSize, maxSize); I do not have a sane build environment to test patches and dumping of the values but I will try to set one up as time permits. If anybody wants to take a look, I'd appreciate any insight/guidance into these changes. I am attaching the diff to the ticket.
The xprop utility may be useful to start investigating here. Much of the communication between the browser and the window manager is through properties on the toplevel window. Most of the rest of communication is through client messages. Attachment 519832 [details] may be helpful for watching those. Run without any arguments. Size constraint communication is documented at http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.4 and maximizing at http://standards.freedesktop.org/wm-spec/wm-spec-1.5.html#idp6314016
Confirmed on NetBSD/amd64 6.1.4 with Firefox 28 and OpenMotif 2.3.3 as well. It seems this is a unilateral issue since the daily build after 2012-07-31. Note that I have not tested any 32 bit architectures yet, so I don't know if this could be related to integer logic (seems unlikely).
This is an issue in Arch Linux 64 bit, Firefox 42.0, OpenMotif 2.3.4. For anyone that does stumble upon this, there is a workaround. If you set the Mwm*Firefox*maximumClientSize X resource small enough, Firefox will maximise to the correct size. In my case, I have a screen resolution of 1366x768. After some trial and error, I found that setting the maximumClientSize for Firefox to 1052x670 made Firefox maximise correctly.
still an issue with Firefox 45.0.2 on FreeBSD 10.3-STABLE r297790M with open-motif-2.3.5.
Priority: -- → P4
Whiteboard: tpi:+

Confirmed still an issue on FreeBSD 13 with open-motif-2.3.8 with 73.0 (64-bit).

Still a problem with FF 86.0.1 however under CDE it's ok.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: