62740 - Do not bring a refreshed window in front of modal dialog window.

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[hirata masakazu]

MTrunk 2000121208.
1. Open more than one window.
2. In one window, try to load a site which takes a long time, or automatically
reloads its content and get brought to the front intermittently.
3. Switch to another window.
4. File|Open Web Location.
5. A modal dialog to enter the URL appears.
6. If you wait long enough, the window in the back is brought to the front and
hides the Open Location dialog.
7. Now, the window in the front does not respond to your mouse click except
close box and window shade switch.
  Of course you can either close or pull up the window by the two switches to
reach the dialog.  Yet, this is bewildering and confusing enough.  Any dialog
that requires attention and block any other input should not be hidden from the
user.
  I suspect that there are some other occasions where a modal dialog wainting
for user input is hidden by browser window.

Comment 1

[Fabian Guisset]

Also see bug 55691 for the window popping up.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Duplicate of old old bug

*** This bug has been marked as a duplicate of 28467 ***

Comment 3

[hirata masakazu]

I do not think this particular bug is a dupe of bug 28467, since 28467 is a
general problem with window positioning in z-axis.
After reading bug 62649, I believe this should be reopened and bug 62649 should
be duped to this one, or vice versa.  I am reopening this here and ask people to
decide the way to dupe because the summary for bug 62649 does not describe the
true problem.

Comment 4

[Asa Dotzler [:asa]]

over to Apps.

Comment 5

[Chris McAfee]

yes, I think this is a dup of bug 28467

*** This bug has been marked as a duplicate of 28467 ***

Comment 6

[timeless]

vrfy dupe of bug 28467 Windows switch z-order when running a URL

Comment 7

[Jesse Ruderman]

I also don't think this is a duplicate of the z-order bug.  Even if that bug is 
fixed, a window in the background could do window.focus() to bring itself to 
the front, and this problem will still occur.

It sounds like the problem here is that the dialog is modal to the app rather 
than to the window, and so when another window is in front of the dialog, the 
user isn't able to interact with the window.  Is that normal on the Mac, or a 
new bug similar to bug 65521 on Linux?

Comment 8

[hirata masakazu]

As discussed in bug 65521, modal dialogs are modal to app in MacOS, too.
Therefore, this might be helped by the fix for 65521.

Comment 9

[peter]

I am sure you guys know but the patch I have for linux only works with GtkWindow
* so some work will need to be done to get this same thing to work on the mac. I
am sorry about this...but the model should be the same. Or course if a Ti
Powerbook landed on my doorstep I might be able to look at it:P

This same behaviour occurs under linux...but it is not as severe with my patch
as you can still act on that window and a window will not be raised above its
modal dialog(it may raise above another's modal dialog)

Yeah that is the annoying thing that such a system needs to be set up. Gtk and
apparently the mac don't have the concept of window modality built into the
toolkit so we have this problem.

So if you can patch the mac stuff the same way(or even a better one) we can be
atleast where windows is on modality. I guess there are some benefits to being
last to the party:p

Comment 10

[hirata masakazu]

It seems that the Password input dialog for Mail always stays at the top. If
that is the case, there must be a way to make other modal dialog to come to the
front whenever it has focus.

Comment 11

[Blake Ross]

Dan, any thoughts here?  Is this toolkit or ours (sounds like the latter)?

Comment 12

[Dan M]

It would be toolkit. My bug, really. It's widget code that's disabling all other 
windows when a modal window is up, and widget code should prevent a nonmodal 
window from forcing its way above a modal one. This was working at one point, but 
I suppose it's bit-rotted.

Comment 13

[hirata masakazu]

This has gotten worse in recent builds. 2001062914 trunk shows the warning
dialogs too early, subsequently covered by the updated window.
Needs to be fixed.
Nominating for 0.9.3 to draw attention to this problem.

Comment 14

[Viswanath Ramachandran]

I'm reassigning to danm, and ccing pink and saari. adding nsbeta1 keyword to get 
oun xptoolkit triage radar. 

Comment 15

[Dan M]

This was fixed along with bug 84047.

The conditions to reproduce are no longer valid: the bug where a window would 
bring itself to the front when the page finishes loading has been fixed, and it's 
one of my cherished but doomed hopes that it remains that way. However, you can 
still force a window to come to the foreground. Say

<html><head>
  <script>
    function delayedFocus() {
      focus();
      setTimeout("delayedFocus()", 5000);
    }
  </script>
</head><body onload="delayedFocus()">
  This page focuses itself every five seconds
</body></html>

With current Mac builds, such a page will indeed force itself to the front, but 
not on top of a modal window (because of the fix for bug 84047.)

Comment 16

[John Morrison]

Yep. Verified fix (with bug 84047).

Comment 17

[Margaret Chan]

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