311709 - Main browser window stuck in resize.

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[cole]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

The Main browser window gets stuck in a resize and can cause unusual behaviour.





Reproducible: Always

Steps to Reproduce:
1. To get this to work your mouse has to be over the sizebox in the bottom right
and 'not' the frame edges or frame corners.

2. When you resize the main browser window via the sizebox and then right click,
this stops the resizing of the browser window.
Its best if you are resizing the window quickly !  It appears that some internal
state still thinks its being resized.

3. If you move the mouse back over the sizebox (without any mouse buttons
pressed) the window still resizes.  Spuriously the window either resizes to its
minimal extent or sometimes resizes to what appears screen size?


Actual Results:  
N/A

Expected Results:  
N/A

I had a look and this might potentially be the cause of Bug 295970?
It's easy to recreate this and I can reproduce it evertime.

Comment 1

[u63580]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006
Firefox/1.4.1

Seeing this too

Comment 2

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051008
Firefox/1.4.1 ID:2005100805

Easy to reproduce

Comment 3

[Adam Guthrie]

*** Bug 325160 has been marked as a duplicate of this bug. ***

Comment 4

[quentin.ruyant]

I have the same bug but I am unable to reproduce it unless I have the TweakUI "activation follows mouse (x-mouse)" option on.
This TweakUI (microsoft powertoys) option allows focus on mouse hover for windows, so the bug maybe caused by a loss of focus while resizing.

Comment 5

[cole]

I have just tried it and I do not have tweakui installed.
Note you have to be over the sizebox (the ui with the three slashes) and not the frame.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Have I mentioned that I think we should remove the resizer?  ;)

Comment 7

[[e-mail]]

This is because the resizer is implemented in JS and can't do anything useful like capture the mouse or initiate an OS resize.

Comment 8

[cole]

The same happens in the new v2.0.

Comment 9

[Ere Maijala (slow)]

Taking.

Comment 10

[Ere Maijala (slow)]

Attachment: Patch v1

The problem was that right-click ended mouse capture, but left button was still down. This is a patch to make widget layer only release mouse capture if no button is down so that resizer or whatever can continue receiving mouse input until any button depressed inside it is released.

Comment 11

[[e-mail]]

Comment on attachment 245068 [details] [diff] [review]
Patch v1

Unnecessary. Just test wParam.

Comment 12

[Ere Maijala (slow)]

Comment on attachment 245068 [details] [diff] [review]
Patch v1

D'oh, of course. A new patch coming up.

Comment 13

[Ere Maijala (slow)]

Attachment: Patch v2

Here's a new very simple patch.

Comment 14

[[e-mail]]

Comment on attachment 245354 [details] [diff] [review]
Patch v2

You can simplify this by a) changing == 0 to ! b) applying De Morgan's Law c) switching from boolean to logical or d) distributing & over | [e) compiler applies constant folding on (MK_LBUTTON | MK_RBUTTON | MK_MBUTTON)]

Comment 15

[Ere Maijala (slow)]

Attachment: Patch v2.1

Point well taken. I like this form. Ok?

Comment 16

[[e-mail]]

Actually I was lazy and when testing I'd just written
CaptureMouse(wParam & (MK_LBUTTON | MK_RBUTTON | MK_MBUTTON));

Comment 17

[Ere Maijala (slow)]

Well, that would of course be even more simple, but I want to keep that |if| there to make it clear and obvious.

Comment 18

[Ere Maijala (slow)]

Fix checked in to trunk.