813997 - Resizing window changes window size to 0 with sawfish

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect)

Description

[mole]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121024073032

Steps to reproduce:

Updated to Firefox 17.0 from 16.0.2.  Started Firefox.  Grabbed lower right corner of window with a mouse click and drag to re-size.

Environment: Debian squeeze with packages including gnome-common 2.28.-0-1 and sawfish 1:1.3.5.2-  Using Gnome with the sawfish window manager.



Actual results:

On starting drag gesture, window shrunk immediately to a width of 0 pixels, showing only a small portion of the window decoration, and none of the window content.  Window can't be maximized or rescaled.   On closing and restarting firefox, window remains at a height and width of 0.  Effect is that firefox disappears when window is re-sized.

Grabbing left or right margins rescales window to a width of 0 with current height.  

Grabbing bottom margin rescales window to height of 0 with current width.  

Grabbing any corner rescales window to height and width of 0.  

To recover a usable window, had to exit firefox, start an old copy of firefox, scale the window to a desired size, exit the old copy, and restart firefox 17.  

Behavior observed on trying to use the  menu option view/full screen was similar to that of Bug 170884, the application does not go to full screen.  


Expected results:

Dragging the window with mouse click and drag gestures should allow the window to be re-sized to any arbitrary size.  This (the normal behavior of a window) is the behavior observed in firefox 16.0.2.

Comment 1

[Matthias Versen [:Matti]]

Could you do a regression range search ?
We have an automated tool that helps with this task - https://github.com/mozilla/mozregression

I would use for example 2012-04-01 as start date

Comment 2

[Karl Tomlinson (:karlt)]

Please also check that the bug still exists when starting with -safe-mode.

Comment 4

[Karl Tomlinson (:karlt)]

Potentially triggered by bug 357725.
Comparing nightly builds from 2012-07-31 and 2012-08-01 could support that.

Can someone run "xprop | grep -A4 WM_NORMAL_HINTS" and click on the firefox window (before it gets resized to zero), please?

Comment 5

[Karl Tomlinson (:karlt)]

Looks like sawfish would be truncating 0x40000000 to 30 bits, making the max size zero.

http://git.tuxfamily.org/?p=sawfish/main.git;a=blob;f=src/windows.c;h=c6117e778ad157f9868c431efa934964b88897fd;hb=HEAD#l1319
http://git.tuxfamily.org/?p=librep/main.git;a=blob;f=src/rep_lisp.h;h=bd537c9dda0224cfe11483e1ec628bf0de5f2766;hb=HEAD#l53

It would be appropriate to not set GDK_HINT_MAX_SIZE if mMaxSize is NS_MAXSIZE,NS_MAXSIZE, which would workaround this bug.
http://hg.mozilla.org/mozilla-central/annotate/3c67034ba39c/widget/nsIWidget.h#l1645
http://hg.mozilla.org/mozilla-central/annotate/3c67034ba39c/widget/gtk2/nsWindow.cpp#l939

That doesn't workaround the bug if only one dimension is NS_MAXSIZE.
Possibly that should be addressed in sawfish, but the X server doesn't support window sizes greater than 0xFFFF even though size requests are passed as CARD32, so limiting the maximum size to 0xFFFF would be quite reasonable.

Comment 6

[Matthias Versen [:Matti]]

marking new based on the dupe

Comment 7

[sldev]

Please note that the priority for this bug is way too low: for me (and everyone using Sawfish), it's a *show stopper*, and something I never saw happening in Sawfish with any other software (and I'm using this wonderful window manager since day one, when it was still "Sawmill") !

If this bug is not fixed in the next Firefox versions, I will have no other choice than to switch to another browser...

Comment 8

[Paul Szabo]

As requested in comment 4:
psz@como:~$ xprop | grep -A4 WM_NORMAL_HINTS
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified minimum size: 18 by 90
                program specified maximum size: 1073741824 by 1073741824
                window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
psz@como:~$

Comment 9

[Paul Szabo]

In comment 5:
> Looks like sawfish would be truncating 0x40000000 to 30 bits, making the max size zero.
> ... limiting the maximum size to 0xFFFF would be quite reasonable.

Would it help to use 0x3FFFFFFF instead of 0x40000000?

Comment 10

[Jakub Travnik]

I can confirm the bug appeared upon update from Firefox 16.0.2 to 17.0 on two of my Debian Linux computers (one is 32bit Intel, other is 64bit with 64bit Linux) for accounts where sawfish is used. When I switch to metacity, problem disappears.

jakub@jtra:/$ xprop | grep -A4 WM_NORMAL_HINTS
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified minimum size: 18 by 146
                program specified maximum size: 1073741824 by 1073741824
                window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST

Above output is same for both sawfish and metacity.

The current behaviour is quite strange in this way:
when I drag resizing decoration by mouse (example: right border), it gets reset to zero size, moving more to the right does not change it, but if I drag it in oposite direction (more to the left than where left border), it gets enlarged to minimum size.
So perhaps the number is interpreted as negative - the "4" hex digit might be directly matching the sign bit so it is interpreted as most negative number. In this case 0x3FFFFFFF would be ok.

Bug is in sawfish/librep, but if it could be workarounded in Firefox, I would be happy.

Comment 11

[Karl Tomlinson (:karlt)]

Yes, 0x3FFFFFFF would be OK, but we already try to limit the size of the window for other reasons, so it makes sense to tell the window manager that limit.

Comment 12

[Karl Tomlinson (:karlt)]

Attachment: keep window max size to 16 bits

unifying size constraint code.

This has the side effect of changing the meaning of GetSizeContraints to
return real constraints rather than what was passed to SetSizeContraints.
That is what nsResizerFrame wants anyway.

A test build is at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-c5b2be4bda47/try-linux/
It is based on Nightly, so either use a separate profile or back up your profile.

I wasn't able to reproduce the missing maximize button, so I'm keen to hear if you were missing that, but this patch resolves the issues with resizing and maximizing the window.

Comment 13

[Paul Szabo]

Confirming that KarlT's 20.0a1 solves the resize issue, including that the
maximize button is back (running on Debian squeeze). Thanks!

Comment 14

[Jakub Travnik]

I can also confirm that Karl Tomlinson's test build solves the issue.

Comment 15

[Karl Tomlinson (:karlt)]

Attachment: keep window max size to 16 bits v1.1

Same as described in comment 12, but also limits minimum size because minimum size overrides maximum size in nsBaseWidget::ConstrainSize().

Comment 16

[sldev]

I can confirm that 20.0a1 also fixes the bug for me (yay !), but please, tell us we won't have to wait till v20 is out ?... The next Firefox release should include your patch; running an outdated browser (for now v16.0.2 for me, since newer browsers can't work under Sawfish) containing known (and therefore more easily exploitable) security holes is dangerous...

Comment 17

[Takanori MATSUURA]

(In reply to sldev from comment #16)

You can add approval-mozilla-{aurora, beta, release, esr17}? flags to the patch.
If the patch is not applied directly to the specific repository, it may be welcome that you prepare the updated one.

See https://wiki.mozilla.org/Tree_Rules

Comment 18

[Karl Tomlinson (:karlt)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2a0696abb60c

Comment 19

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/2a0696abb60c

Comment 20

[Karl Tomlinson (:karlt)]

Comment on attachment 685776 [details] [diff] [review]
keep window max size to 16 bits v1.1

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
Major regression in 17 for some users.
User impact if declined: 
The regression here affects only a small subset of users, but for those users the browser is practically unusable.

Testing completed (on m-c, etc.): on m-c
Fix Landed on Version: 20

Risk to taking this patch (and alternatives if risky):
Low.  Affects only X11 port.  The fix involves changing the limits on window sizes from cosmic dimensions to just very large.  The largest risk would be for users with monitors adding up to more than 32767 pixels in any dimension, a situation that I would not expect the X server to handle well.

String or UUID changes made by this patch: None

Comment 21

[Karl Tomlinson (:karlt)]

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 357725

Comment 22

[Lukas Blakk [:lsblakk] use ?needinfo]

This is not a valid bug for the ESR branch - it affects Linux users and I don't believe we have many users in large scale, organizational deployments on Linux. Happy to take uplift for this low-risk patch to branches though.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/9a66d101d4ff
https://hg.mozilla.org/releases/mozilla-beta/rev/56e523ad7f2f

Comment 24

[Mihai Morar, (:MihaiMorar)]

Verified fixed on FF 18.b4 Ubuntu x86 Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0 (20121212073002)

Comment 25

[Jakub Travnik]

Verified fixed on Czech FF version (Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0)

Comment 26

[Mihai Morar, (:MihaiMorar)]

(In reply to MarioMi from comment #24)
> Verified fixed on FF 18.b4 Ubuntu x86 Mozilla/5.0 (X11; Linux i686; rv:18.0)
> Gecko/20100101 Firefox/18.0 (20121212073002)

Verified Fixed on FF 19b2 too.

Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20100101 Firefox/19.0(20130116072953)

Comment 27

[Mihai Morar, (:MihaiMorar)]

(In reply to MarioMi (:MarioMi) from comment #26)

I confirm the fix is verified on FF 20.b1 too, on Ubuntu 12.04 x86:

Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0(20130220104816)

Comment 28

[Matus UHLAR - fantomas]

I've had different problem in olvwm, and fixed it by not specifying maximum window size at all.
Defining minimum window size has its logic, but I don't see any logic behind specifying maximum window size...
Jus FYI

Comment 29

[Matus UHLAR - fantomas]

Attachment: dont set maximum window size

here's patch that avoids specifying maximum window size, the minimum should be enough. I don't see reason to specify random huge size if it's not functional issue

Comment 30

[Matus UHLAR - fantomas]

okay, this prolem still persists, in some window managers the maximized window is set to insanely huge value.
The real solution is even more simple than the original in this bug: do NOT specify maximum window size.
Is it possible to reopen this bug or should I open new one?

Comment 31

[Paul Szabo]

Dear Matus, in comment #28 you wrote about a "different problem in olvwm".
Could you describe the actual problem? Seems that not many other people
have problems now, so this issue is being ignored. (I am no Mozilla developer,
so would not be able to help in actually having a fix implemented.)

Comment 32

[Matus UHLAR - fantomas]

I explained the problem in comment 30, but I'll repeat:

Firstly, I've had the same problem (size 0) as originally described here.
After the original fix, maximizing window caused the window to be incredibly huge (32767x32767).

The fix, that works in all managers I have yet tried, is in the attachment 8425573 [details] [diff] [review] - not specifying maximum size works as it should.