74053 - stacked dialogs once closed confuse focus and activate wrong window

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Dan M]

This is a reminder bug, serving notice that the true problem underlying a 
couple of other bugs, now closed, still remains.
  The Windows OS chooses a surprising window to activate once a stack of 
dependent (or modal, in our case) windows has been closed. That is, if a 
dependent and or modal window itself opens another window, once both those 
windows are (made active and) closed, you might expect the grandparent that 
originally opened the dependent window would be made active. But in fact it's 
just about the only window that won't be activated. This confuses users, 
especially in Composer which stacks dialogs like this with relish. That's bug 
22658.
  I checked in a fix for this. That fix activates the parent window at an 
unexpected point, causing focus to be confused. That was a raft of other bugs, 
like bug 54936.
  The fix for bug 22658 fired too often; it has since been restricted to just 
dialogs which we noticed opened another child window. That causes bug 22658 to 
regress occasionally (for certain child windows that we don't detect properly, 
like the filepicker) but not for, for instance, Composer's dialogs stacks. This 
restriction apparently fixes most if not all of the focus problems, happening in 
stacks of just one dialog as they were.
  I've closed the bugs mentioned above, since technically they've been fixed. But 
the underlying focus problem still exists and could rise again. It wants a real, 
general fix someday.

Comment 1

[Dan M]

Just noting the particular problem known to remain. It happens when any modal
window opens a non-XUL window. A system filepicker, for instance. An example
just noted in bug 123562 goes so:

Edit->Preferences
Go to Navigator->Helper Applications
Click 'New Type'
Click 'Choose...' to get a system filepicker dialog
Close the filepicker dialog
Close the 'New Type' dialog

Comment 2

[Dan M]

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

Comment 3

[Sean Kendall Schneyer]

Is the Alert dialog a non-XUL window? The reason I ask is that I see this same
problem with the Search dialog:
1) Surf to any page you'd like
2) Hit Ctrl-F to open up the Find in this page window
3) search for something not in the page ("a;sldkfja" usually works for me)
4) Close the Alert
5) Close the Find window
6) Some random window gets the focus

Also, I'm seeing this on Windows 98 and Windows 2000. My current Build ID is
2002020208.

Comment 4

[Dan M]

Yes the alert is a XUL window. There was a recent a regression; see bug 122765.

Comment 5

[R.K.Aa.]

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

Comment 6

[Boris 'pi' Piwinger]

Is this still happening? I haven't seen it lately. Maybe someone can give exact
steps to reproduce or create a testcase.

pi

Comment 7

[djk]

I can reproduce the case in comment 1, but not comment 3, with build 2002073004 w32.

Comment 8

[Dan M]

This was fixed in Mozilla 1.4 as bug 189085