modal dialogs become inaccessible

VERIFIED DUPLICATE of bug 25684

Status

()

Core
XUL
P3
normal
VERIFIED DUPLICATE of bug 25684
18 years ago
18 years ago

People

(Reporter: Warren Harris, Assigned: Dan M)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+])

(Reporter)

Description

18 years ago
I've noticed that if the browser brings up a modal dialog (e.g. visit 
ftp://<user>@raquelita) and you click on some other app's window to bring it to 
the front, you can't click on the mozilla window's icon in the Windows task bar 
to bring it (and the modal dialog) to the front again. This can be very 
frustrating because it leads you to believe that the app is hung.

You can iconify all the windows on top of the mozilla windows such that the 
dialog is exposed again and you will see the dialog and realize that it is 
live. However, either there should be a task bar icon for the modal dialog (so 
you can expose it easily), or when the task bar icon of the window putting up 
the modal dialog is clicked, both the window and the dialog should come to the 
front.
(Reporter)

Updated

18 years ago
Keywords: nsbeta2
not a menu bug. dan?
Assignee: pinkerton → danm
Component: XP Toolkit/Widgets: Menus → XP Toolkit/Widgets
QA Contact: sairuh → jrgm
(Assignee)

Comment 2

18 years ago
  This is not exactly a dupe, but comes from the same root cause, as bug 22658. 
Try opening a modal dialog parented on the browser window (most easily done by 
clicking buttons on the Debug Menu -> XP Toolkit -> Dialog page). You won't 
observe Warren's Complaint. The problem is, modal dialogs summoned during network 
access, as in the password dialog mentioned in the bug description above, are 
parented on the hidden window, rather than on the browser window actually 
responsible for creating the dialog. Lacking a connection between the two, 
Windows will ignore mouseclicks on anything but the modal dialog itself.
Status: NEW → ASSIGNED
Depends on: 27048
Target Milestone: --- → M18

Comment 3

18 years ago
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]

Comment 4

18 years ago
Unsurprisingly, this bug also comes alive when a "Confirm Cookie" dialog
gets hidden behind another app's window. For a user with a modem link,
that is an entirely possible scenario...rather than wait for a page like
www.cnn.com to finish drawing, the user may do something else meanwhile.

Also, ALT-TAB is *not* a workaround.

Tested with the 2000-06-05-08-M16 nightly binary on WinNT.
(Assignee)

Updated

18 years ago
No longer depends on: 27048
(Assignee)

Comment 5

18 years ago
  This is really a duplicate of bug 25684 -- modal dialogs aren't quite. Since 
I've just gone to a lot of trouble to make that bug a placeholder for all the 
work that needs to be done to clean up modal dialogs usage in Mozilla, I'm 
closing this bug and pointing it at that one.


*** This bug has been marked as a duplicate of 25684 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 6

18 years ago
Verified duplicate.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.