103031 - Dragged windows unexpectedly close when their top left corner intersects the close widget on another window

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[lchiang]

Bringing a background window to front causes it to disappear completely

2001-10-03-04-094 build although I've seen this over the last few days when I
switched to using OS X builds fulltime.

I don't have the exact steps just yet, but I can reproduce this fairly
consistently on the Powerbook located in the engineering pit.   Jussi reports he
sees this often and I've seen this many times on the iMac in my cubicle.

OS X and 10.1.

1.  Two windows (ie. browser) are open.
2.  Click on the title bar area of the window in the background to bring it to
the foreground.
3.  The window you just clicked on closes.

Note: I've also seen the case where as a result, all the menu items except for
the Netscape menu are gone.  You have to cmd+N to open a new window in order to
bring the menu back.

I'll try to narrow down further.

Comment 1

[Steve Dagley]

I don't know if this is the problem but note that if you click in a background 
window _and_ the click is in the close widget the window will close rather than 
coming to the foreground.  It appears to be a standard OS X behavior as IE does 
the same thing.  This is _not_ the same behavior as under OS 9.

Comment 2

[Simon Fraser [no longer active]]

I've seen windows disappear like this too, and I'm pretty sure that I didn't 
click the close widget of the background window.

Comment 3

[lchiang]

The cases where I've seen this (but can't make happen at will) were times where
I clicked in the middle of the title bar.

In the engineering pit's Powerbook, I am clicking close to the X button where I
can see it all the time (perhaps what you were talking about, Steve).  However,
that would not explain why all of the menu items disappeared when this happens.
 If you want, I can show you on that computer.

I will try more to see if I can get a case.  I see this in all aspects of using
this application:  my Inbox closes or my IM window closes or my browser window
closes.    

Comment 4

[Steve Dagley]

that the menus are disappearing is a definite sign that we're closing the window 
when clicking in it rather than bringing it to the foreground and then closing 
it.  Why the click to bring to the forgeround is being interpreted as a click in 
the close widget is the mystery

Comment 5

[lchiang]

The strange thing is that the remaining window doesn't have the menus showing
except for the Netscape menu item.  

I am also experiencing the disappearing window symptom when I try to move my
current window around the screen.

This is bothersome to me.  I will continue to find steps.  Have you seen this
before Steve?  Do you want me to show you in the engineering pit's machine
(before someone takes it away)?

Comment 6

[Steve Dagley]

Bug #75946 is the disappearing menu bar when clocing background windows bug

Comment 7

[lchiang]

Observation:  I notice that I see this more if the window currently in the
foreground is doing some sort of an operation (ie. loading a page, sending
progress dialog).  Still trying to figure out....

Comment 8

[J Luh]

This is similar to or the same as bug 79968. It's very annoying. Please fix!

Comment 9

[J Luh]

See bug 79968 for steps to reproduce

Comment 10

[Steve Dagley]

while bug 79968 is likely the same bug, all the repro cases added to it were for 
jumping windows, not disappearing ones.  AFAIK, nobody has yet found a 100% repro 
case for disappearing windows

Comment 11

[J Luh]

Here are steps to reproduce this:

1. Create a new profile. Launch Mozilla. (Mozilla brings up a Navigator
window.)2. File->New->Blank Page to Edit.3. Open Address Book. Click Cancel and
Exit to dismiss dialogs.
4. Move the Address Book window out of the way by dragging its title bar.
5. Click on the title bar of the Editor window.

Editor window vanishes.

Comment 12

[Steve Dagley]

That repro case doesn't work for me (but the @#$% address book window moves its 
titlebar well above the menu bar when I release the mouse after dragging it)

Comment 13

[J Luh]

Part of the problem seems to be that a new window is created so that its upper
left corner is inside the close button of the other window; this triggers bug
79968 next time you click on the title bar of the new window. Try this:

Open two navigator windows. Drag the active window so that its close button is
directly on top of the upper left corner of the inactive window. Bring the
inactive window to the front using the Tasks menu. Click on the title bar of
this window (formerly the inactive window, now active). The window vanishes.

Comment 14

[J Luh]

Slightly easier steps to reproduce:
1. Start Mozilla with a new profile. Mozilla opens a navigator window.
2. File->New->Blank Page to edit. Mozilla opens an editor window (notice that
its upper left corner appears is on top of the navigator window's close button).
3. Select the navigator window in the Tasks menu to bring it to the front.
4. Click on the title bar of the editor window. Editor window vanishes.

Comment 15

[Steve Dagley]

spank me with a wet noodle, I don't even have to select the inactive window.  
Just drag the foreground window so its top left corner is over the close button 
for the background window, let go and the foreground window will disappear.  It 
doesn't matter what background window so if you have lots of windows open you've 
got more opportunities to run into this bug.

Applying magic keywords to bring to PDT's attention - not that we have a fix yet.

Comment 16

[J Luh]

The dragging problem described by sdagley 2001-10-08 19:30 is addressed in bug
79968. This bug report covers windows disappearing when you click on a background
window's title bar to bring it to the front. If you are combining these into one
bug, you can probably close bug 79968.

Comment 17

[Jaime Rodriguez, Jr.]

um ... should this be nsbranch+, since we have OSX+ (i.e. Is this a stop-ship
for OSX)?

Comment 18

[Steve Dagley]

This bug is actually that dragging ANY window, be it active or inactive, and 
releasing it with the top left corner of the window being over the Close widget 
of ANY other window results in the dragged window being closed.  Now that we've 
discovered how reproducable this is we most certainly want to get a fix for this.  
If only it were obvious what the fix was :-(

Comment 19

[Steve Dagley]

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

Comment 20

[Simon Fraser [no longer active]]

This is the cause:
http://lxr.mozilla.org/seamonkey/source/widget/src/mac/nsMacMessagePump.cpp#586
We're slamming the top-left of the window structure region into the OS event 
struct.

Comment 21

[Simon Fraser [no longer active]]

Attachment: Fix in nsMacMessagePump

Comment 22

[Simon Fraser [no longer active]]

So here's the deal.

nsMacMessagePump::DoMouseDown() handles the 'inDrag' event in a window by
calling DragWindow(), then passes the event down to raptor so that it can
respond to window moves. The bad thing was that the code used to do this:

    RgnHandle strucRgn = NewRgn();
    ::GetWindowRegion ( whichWindow, kWindowStructureRgn, strucRgn );
    Rect strucRect;
    ::GetRegionBounds(strucRgn, &strucRect);
    ::SetPt(&anEvent.where, strucRect.left, strucRect.top);
    ::DisposeRgn ( strucRgn );

slamming the top-left of the window structure region into the event.where field
before calling DispatchOSEventToRaptor(). Unfortunately, down in
nsMacMessageSink::DispatchOSEvent() we throw away the WindowPtr that we've got,
and rely on nsMacEventHandler::HandleMouseDownEvent() to call FindWindow() a
second time to get the window that the event was destined for. The problem, on
X, is that windows have rounded corders, and that (0, 0) is thus outside the
bounds of the frontmost window, but, alas, hits some pointer in windows behind.
Thus is why background windows' widgets which lay under the top-left of the
frontmost window got hit.

I think this would also have happened if you were running a funky Kaleidoscope
theme under 9 that had non-square window corners.

The fix is to use a better technique to 'fix up' event.where after the
DragWindow. Rather than just use the top-left of the window, just offset the
event.where with the amount that the window moved.

Comment 23

[Steve Dagley]

Comment on attachment 52678 [details] [diff] [review]
Fix in nsMacMessagePump

r=sdagley (after being on the phone so long the connection time display has rolled over)

Comment 24

[David Hyatt]

sr=hyatt

Comment 25

[Steve Dagley]

Reassigning to sfraser as we've decided he's foo, er, brave enough to actually 
land this on branch and trunk.

Comment 26

[Simon Fraser [no longer active]]

Checked into trunk and 0.9.4 branch. Rejoice.

Comment 27

[Simon Fraser [no longer active]]

Er:
s/hits some pointer in windows behind/hits some point in windows behind

Comment 28

[Steve Dagley]

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

Comment 29

[Steve Dagley]

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

Comment 30

[J Luh]

Yup, this seems to be fixed now.

Comment 31

[Steve Dagley]

After sleeping on it I don't think this would happen under 9 after all.  The 
ability to click on the close & zoom widgets of background window is new with X.  
Without that behavior, FindWindow() should have returned inDrag to indicate a 
click in an inactive window.

Comment 32

[Pierre Saslawsky]

Nice catch!

sdagley: correct.  On OS9, if you click the location of the close box on a 
background window, you get 'inDrag' and you can start dragging if the cmdKey is 
pressed.

Comment 33

[Jaime Rodriguez, Jr.]

pls check this in ... doh! ... its already there.

Comment 34

[lchiang]

Wonderful!  After one day's use, I am not seeing this bug any longer, but will
leave bug open for more verification.

Comment 35

[sairuh (rarely reading bugmail)]

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

Comment 36

[J Luh]

This problem seems to be back in Mozilla 0.9.5

http://ftp.mozilla.org/pub/mozilla/releases/mozilla0.9.5/Mozilla095forMacOSX.smi.bin

Was the fix applied to the Mozilla 0.9.5 builds, or just the 0.9.4 builds?

Comment 37

[lchiang]

When was the 095 branch made?  This was checked in on 094 and trunk and may have
missed 095 if the branching occurred before the fix was checked in.

Comment 38

[John Morrison]

0.9.5 branch was cut 10/05, and this is not on that branch (which is now water 
under the bridge).

Comment 39

[John Morrison]

well, I can't make this happen in the candidate 0.9.4. build, but then I couldn't 
make this happen before the patch went in (these kind of things happen to you 
when you're not so bright). 

If someone can give this a definitive 'a-ok' for the 0.9.4 build, please go ahead 
and mark this vtrunk (or just verified if both 9.4.branch and trunk). 

Comment 40

[lchiang]

I'll do the verification because I was seeing this bug all the time and no
longer see it.  I can only verify on the 094 branch for now.

Comment 41

[svbegg]

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