Since bug 118299 was checked in, there is now a resizer on the right of the Firefox status bar on Linux, like on Windows. If I try to resize a window by dragging it, the mouse cursor does not stay inside the resizer. This can have some bad effects, like keeping the window in a resizing state even when you release the mouse button, or having the window move in unexpected ways.
This bug is definitely noticeable and definitely a major annoyance in major linux usage. Steps to reproduce: EXPERIMENT A: 1. Hover mouse over Firefox's lower-right resizer, so that the resizing cursor appears. 2. Still hovering, move mouse as far to the upper-left as you can while still keeping the resizer cursor. 3. Now, click and drag directly to the right, or directly downwards (or any combination of those), as if you were trying to make the window larger. OBSERVED RESULTS: Resizer cursor moves outside window while you're resizing. Window doesn't keep up with mouse, and it flickers large gray chunks at its edges a lot. EXPERIMENT B: Steps 1-2: Same as in Experiment A. 3. Now, click and drag to the upper-left, into the window, as if you were going to make the window smaller. ** Observed results: though you're still holding mouse button down, cursor switches back to an arrow and the resizing operation stops. 4. Release mouse button, inside the window. Cursor remains an arrow. 5. Move cursor outside of the right or lower border of the window. OBSERVED RESULTS: When the mouse cursor exits the window, the (broken) resize operation resumes, even though you're not holding down the mouse button. The only way to cancel this operation is to click while the cursor looks like a resizer. EXPERIMENT C: Steps 1-4: Same as in experiment B. 5. Move cursor outside of the left or top border of the window. OBSERVED RESULTS: Firefox window disappears!!! When exiting left side, I get this assertion: ###!!! ASSERTION: reflow state computed incorrect width: 'reflowState.ComputedWidth() == size.width - reflowState.mComputedBorderPadding.LeftRight()', file /scratch/work/builds/trunk.07-12-05.11-16/mozilla/layout/base/nsPresShell.cpp, line 6175 It seems that the only way to *correctly* resize the window with the lower-right resizer is to drag from its absolute bottom-right corner. Then, things work pretty well.
(In reply to comment #1) > OBSERVED RESULTS: Firefox window disappears!!! Note: This is NOT a crash -- the window just plain disappears. It's gone from the taskbar, also.
+'ing with P3.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Created attachment 291937 [details] [diff] [review] Nuclear option Since this bug also stumps me, and with beta 2 nearly ready, this may be our only option. It may also be our best option, knowing that the resizer now causes serious dataloss with disappearing windows. But we need to do something before beta 2.
Comment on attachment 291937 [details] [diff] [review] Nuclear option We need this for M10 to stop the carnage caused by this 15x15 abomination. This returns to Fx2 behaviour of no resizer.
Attachment #291937 - Flags: approvalM10?
Comment on attachment 291937 [details] [diff] [review] Nuclear option Approved to land for beta2. Thanks for the patch!
Attachment #291937 - Flags: approvalM10? → approvalM10+
We've had similar trouble with the resizer on Linux. CC'ing Ian.
Nuclear option checked in: Checking in nsNativeThemeGTK.cpp; /cvsroot/mozilla/widget/src/gtk2/nsNativeThemeGTK.cpp,v <-- nsNativeThemeGTK.cpp new revision: 1.119; previous revision: 1.118
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Why closing? This does not fix the real issue. Having a XUL resizer on Linux could be wanted.
Fixing this really isn't too hard. The patch that's about to go into Songbird works pretty well.
Michael reopened bug 118299, so it could be the one tracking this issue.
(In reply to comment #13) > Michael reopened bug 118299, so it could be the one tracking this issue. > Yes, that was my intention.
Great, then let's leave this one closed and use bug 118299 for re-enabling a fixed version of the xul resizer.
(In reply to comment #12) > Fixing this really isn't too hard. The patch that's about to go into Songbird > works pretty well. Do you mean you fixed this for Songbird? Do you have a pointer where that patch can be found?
Well, for Songbird I wrote a binding that overrides the xul:resizer binding with one that passes mousedowns to a component that calls into gtk. I think the fix would need to look a little different when it went into the platform. The patch that adds this (and keep-on-top, and enforcing minimum window size) is attached to: http://bugzilla.songbirdnest.com/show_bug.cgi?id=5278 I can look at rolling this into toolkit if there's support for it.
One way I see to fix this for platform would be to add the BeginResizeDrag / GetSupportsResizeDrag API on nsIWidget and use that instead of the manual resizing from layout/xul/base/src/nsResizerFrame.cpp if available.
That's what I'd like to do. I'm not sure if I should add a new interface or add it to nsIWidget. If I added a new interface we wouldn't even need a GetSupportsResizeDrag since the presence of the interface would indicate support. I'll throw together a proof-of-concept patch some time in the next few days.
(In reply to comment #20) > Not being a part of the development of Mozilla, I have to wonder why this bug > still exists. I'm confused... what bug are you talking about? This bug here was fixed in current trunk over a month ago, and the remaining issue (bug 118299, as stated in comment 15) was fixed a few days later. Is there a bug here that "still exists"?
I am using 126.96.36.199, and when I attempt to resize a browser window, it jumps all over the window, and at times it moves to a different viewport, resulting in a 3 pixel wide window that I have trouble finding. I am running Ubuntu 7.10, and Compiz Fusion is in use. I doubt that the error is arising as a result of my configuration. I have a skin, but the error seems to occur when the resizer cannot catch up to my cursor before it is hovering over the actual content display area. When the cursor enters the display area, resizing stops but there is no detection that my mouse button has been released. Thus, when I move the mouse back out of the content area, the window begins resizing once again, until I click (triggering the "mouse up" event). Perhaps I am using a version that has not yet been updated to reflect the fix.
Jason, you're welcome to try the Firefox 3 betas, but if you want a stable build, you'll need to wait for Firefox 3. Firefox 3 beta 2 should have this fix.
(In reply to comment #22) > I am using 188.8.131.52, and when I attempt to resize a browser window, it jumps > all over the window, and at times it moves to a different viewport, resulting > in a 3 pixel wide window that I have trouble finding. Firefix 2 doesn't contain the XUL resizer, so whatever you are seeing is not this bug. Looks more like a bug in the window manager or Compiz to me.
The resizer is not a feature of my operating system or window manager, and it looks identical to the XUL resizer I have used on my Windows box. It is without a doubt a part of Firefox. Resizing the window using the absolute corner (ie, using the window manager) works flawlessly. As long as the bug will be fixed eventually, then it's not a big deal. I am quite sure most users assume it is a feature of their operating system. @Samuel: Thanks, I was avoiding using a browser that is in beta, but I will look into it. Perhaps there will also be an option to remove the "File Edit View ..." toolbar without having to install an add-on. If you are uncertain about beta 2, I could give it a try.
See bug 244787, some GTK/Gnome themes seem to include a custom resize area. But the code for the XUL resizer has never been part of the 2.0 branch AFAIK (and I certainly don't see one on my Debian system with Firefox 184.108.40.206). Anyway, this is fixed on Gecko/2008011604 Minefield/3.0b3pre, marking verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.