Closed Bug 813997 Opened 8 years ago Closed 8 years ago

Resizing window changes window size to 0 with sawfish

Categories

(Core :: Widget: Gtk, defect)

17 Branch
x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla20
Tracking Status
firefox17 --- wontfix
firefox18 --- verified
firefox19 --- verified
firefox20 --- verified
firefox-esr17 - wontfix

People

(Reporter: mole, Assigned: karlt)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

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.
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
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Please also check that the bug still exists when starting with -safe-mode.
Duplicate of this bug: 814972
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?
Keywords: regression
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.
Blocks: 357725
marking new based on the dupe
Status: UNCONFIRMED → NEW
Ever confirmed: true
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...
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:~$
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?
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.
Assignee: nobody → 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.
Attached patch keep window max size to 16 bits (obsolete) — Splinter Review
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/ktomlinson@mozilla.com-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.
Confirming that KarlT's 20.0a1 solves the resize issue, including that the
maximize button is back (running on Debian squeeze). Thanks!
I can also confirm that Karl Tomlinson's test build solves the issue.
Same as described in comment 12, but also limits minimum size because minimum size overrides maximum size in nsBaseWidget::ConstrainSize().
Attachment #685492 - Attachment is obsolete: true
Attachment #685776 - Flags: review?(roc)
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...
(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
https://hg.mozilla.org/mozilla-central/rev/2a0696abb60c
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Flags: in-testsuite-
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
Attachment #685776 - Flags: approval-mozilla-esr17?
Attachment #685776 - Flags: approval-mozilla-beta?
Attachment #685776 - Flags: approval-mozilla-aurora?
[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 357725
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.
Attachment #685776 - Flags: approval-mozilla-esr17?
Attachment #685776 - Flags: approval-mozilla-esr17-
Attachment #685776 - Flags: approval-mozilla-beta?
Attachment #685776 - Flags: approval-mozilla-beta+
Attachment #685776 - Flags: approval-mozilla-aurora?
Attachment #685776 - Flags: approval-mozilla-aurora+
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 Czech FF version (Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0)
(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)
(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)
Status: RESOLVED → VERIFIED
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
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
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?
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.)
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.
You need to log in before you can comment on or make changes to this bug.