* Overview: The potential confusion reported in bug 10000 no longer seems possible, but a fix applied to the "Open Web Location" dialog to address that confusion is causing usablility problems. Since bug 10000 was opened, the "Open Web Location" dialogs (a) no longer appear on the Taskbar, (b) and have been made modal. (c) When the parent of that dialog re-appears, so does the dialog. Points (a) and (c) emulate the very useable behaviour in Communicator 4.7; point (b) causes usability problems. In the situation described by bug 10000's reporter, the Communicator 4.7 behaviour seems entirely sensible and adequate, for File>Open Web Location and File>Open File, and the current Mozilla behaviour seems profoundly broken from a UE perspective. * Steps to Reproduce: In Communicator 4.7 on all Win32: 1. User starts Communicator, the browser appears. 2. User causes another browser window to appear. 3. User causes Messenger to appear. 4. User brings up File>Open Page dialog in first browser. Nothing is added to the taskbar at this point. 5. User switches to second browser window, does anything. 6. User switches to Messenger windows, does anything. 7. User switches back to first window. The "Open Web Location" dialog is displayed on top, right where the user left it. In Mozilla 1999-11-16-08-M12 on WinNT (likely all Win32): 1. User starts Mozilla, the browser appears. 2. User causes another browser window to appear. 3. User causes Mail window to appear. 4. User brings up File>Open Web Location dialog in first browser. *Nothing is added to the taskbar at this point.* 5. User switches to second browser window, tries to do anything, but the UI is entirely unresponsive. Any and all windows seem frozen, giving the appearnce that Mozilla as a whole is frozen, so long as the user manages not to return to the first window. 6. User switches to Messenger windows, tries to do anything, at which point the entire App crashes, killing all windows. 7. (Reached if step 6 is skipped) User switches back to first window. The "Open Web Location" dialog is displayed on top, right where the user left it. Actually, the dialog appears first, then the window under it. * Expected results: Mozilla should act like Communicator 4.7 - All windows remain usable, and the "Open" (or any other) dialog reappears in context when its parent is given focus. The current behaviour matches this except for the modality of the dialog. * Actual Results: If an "Open Web Location" dialog is left hanging, it is possible to switch to other Mozilla windows, but nothing can be done in them until the dialog is used or dismissed. All windows appear frozen, and effectively are until the "Open Web Location" dialog is used or dismissed. (Currently, if the first window is clicked on it will incorrectly get a highlighted Title Bar, despite being blocked, making the UE worse yet, but that's a different bug - reported already, IIRC) * Suggested Fix: Back out the modality added to the "Open Web Location" dialog. * Tested with: 1999-11-16-08-M12 nightly binary on Windows NT 4.0sp3 Communicator 4.7 on same OS. * Additional Information: Here's what I think that a naive user would want in general terms: A. If a browsing/compositor/mail-news/whatever main window is given focus by taskbar selection, ALT-TABbing, Task Manager selection, or any other means, once it appears on top, it should signal any dialog window it may be waiting on to display itself on the very top of the window stack. B. If a dialog windows that a main window is waiting on is given focus, it should first signal its parent to display itself at the top of the window stack before diaplaying itself at the top. C. No blockage of the UI in other windows no matter what one window is waiting for. Communicator 4.7, possibly earlier versions as well, does A. B. may never in fact be needed. The only dialog I can think of that Communicator places on the Taskbar (and task list) where it can be independently reached is the "Saving Location" Dialog (the one after the "Save Page As" dialog), which has effectively been cast off - neither the parent window nor the child need to keep tabs on one another. If it is needed, it should get split off as a new bug report, and the practical problems of dialogs knowing and notifying their parents noted in bug 10000 will be apropos. Some earlier versions of Communicator and previous netscape browsers did not meet expectation C.

reassign it to sdagley to see the relationship between this bug and #10000. also cc german on this one to make sure the spec and implemetation are match.

This behavior is also replicated by: a) open a browser window b) open composer c) type something d) close composer but don't respond to the Save/Don't Save/Cancel dialog e) go back to the browser window The browser window responds to almost no events, although it seems that _sometimes_ mouse-over events and menus work.

Since this is not specific to the file open/save dialogs, it is more DanM's area. Reassigning to him, targetting p3 for m14. removing dependency on 10000, despite their similaritiy, and possibly having the same solution, there is no demonstrated dependency relationship.

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

Putting on beta1 radar.

Putting on PDT+ radar for beta1. Good bug :-)

Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.

Requesting re-evaluation of PDT+-ness. I claim this problem is fixed on Windows and Linux. I've chipped away at this problem until it's become a Macintosh- specific failure to keep new nonmodal windows out of the hair of extant modal ones. This can happen in a variety of ways: Dean's example above, Simon's example outlined in bug 24663, or careless JavaScript, for instance. In all cases, an unresponsive window pops into the foreground. There's a workaround that always works: the user has to click on the modal window to reactivate it. The right solution is to implement a Z-ordering mechanism that will, among other things, keep new windows from popping up in front of modal ones. We need this thing and I want to do it, but I think other, larger bugs are wanting my M14 attention. I suggest calling this bug "fixed enough for now."

Putting on PDT- radar for beta1.

Mass-moving most M15 bugs to M16

moving to m18

mass-moving all '-' bugs to M20

nsbeta3-

Adam, Matthew, aside from the leftover details that are the subject of bug 25684, "[crash] modal windows/dialogs are not 100% modal" is this even still a problem at all on the Mac?

This bug is still a problem on Linux as of build 2000110409. I'm unable to do the following: (1) open browser (2) open E-Mail Composer (3) enter a recipient and type some text then click on the window close (X). This will cause a modal window to pop up asking you if you want to save the email. (4) click on the browser and attempt to do something/anything. Is there a schedule for when this will be fixed? It is greatly impacting our application.

This bug describes just a Mac problem. But, the Linux situation you're describing is a condition of the gtk toolkit -- if memory serves, gtk_window_set_modal() sets up an event filter that weeds out events not destined for the window made modal. The unfortunate effect being that modal windows are effectively application modal, not just window modal. It's a gtk thing. We have no plans to ever try to change it. Unless it's our fault for misusing gtk. But lacking an epiphany along those lines, we're stuck with the current behaviour.

danm, we came up with a fix for the gtk modality issue. Check out bug #65521. I would really like a peer review on this one.

Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...

WorksForMe using FizzillaCFM/2002080508 to perform the steps in comment 0, comment 2, and comment 15.

WFM Moz 20030312 OSX.