Steps: 0) Have multiple 4.x windows open 1) My Seamonkey profile automatically launches Navigator and Mail because I imported a previous 4.x profile. Navigator comes up first and then Mail. 2) Top level menus are not working or do not show menu items so this makes the application appear broken. Actual Results: I start minimizing windows and then find the password dialog for mail. Expected Results: This password dialog should be modal and display on top of any open window. Build Date/Platform: 2/16/00-15 on NT
I think ben owns these dialogs now
Assignee: phil → ben
Ben may own the password dialog, but he doesn't own window behavior. Dan, who should get this one?
Assignee: ben → danm
Putting on PDT+ radar for beta1.
I utterly fail to follow you. Step 0: which multiple 4.x windows should I have open? Step 1: I'm very surprised to hear that Mozilla launches Navigator under any circumstances. Or, that's how I read this. Launch Seamonkey, get Navigator. I'm gamely trying that right now and it's just not happening, I'm pleased to say. Step 2: I believe you're saying there was a modal password dialog open somewhere and not on top, eating mouse events in the menubar. But I'd be surprised to hear that the specified platform, NT, behaves that way. Are you sure you're not describing a Macintosh situation? Under what circumstances? Neither Mozilla nor Navigator normally greets me with a modal dialog, not even when I launch -mail. Perhaps I'm being dense, but I haven't a clue what you're trying to describe. Sometimes obvious is best. For me, anyway. Please fill in some blanks for me here.
putting on PDT- radar for beta1. bijals, please supply text for a relnote at: http://bugzilla.mozilla.org/show_bug.cgi?id=25524
Whiteboard: [PDT+] → [PDT-]
I'll have to try to reproduce this bug.
Lisa, I can show you or phil exactly what happens. Basically, the password dialog is not modal and sometimes is up, but not on top. I will show it to Sol so he can describe it better.
I've seen it, and vote for release-noting for beta1
Please reassign this to the appropriate person who will be creating the Mail release notes.
It has the relnote keyword, which is enough. The actual bug belongs to danm. Dan, I think the bottom line to repro is that if you run seamonkey with the startup prefs set to bring up browser *and* mail, and we try to log in to your mail account, the password dialog is behind some other window. Once the dialog is up, some UI events don't get subdispatched in other windows, which makes the app look broken.
Assignee: bijals → danm
Phil, good description. The symptom of the password dialog not being truly modal is that 1) You do not see it on the Windows desk tray like the Navigator and Mail windows 2) You can not use the top level menus in Navigator and Mail 3) I tried to hit get mail and the dialog still did not appear By hitting alt-tab and selecting a 3rd unknown Seamonkey icon, I realized why I could not doing anything until I entered my password in this dialog.
Mass-moving all M16 non-feature bugs to M17, which we now consider to be part of beta2.
Target Milestone: M16 → M17
We need this to work in beta2, nominating.
*** Bug 33590 has been marked as a duplicate of this bug. ***
[nsbeta2+] will take a fix by 6/1
Whiteboard: [PDT-] → [nsbeta2+] 6/1
Mass-moving all dated nsbeta2+ bugs to M19
Target Milestone: M17 → M19
Updating from [6/1] to [6/15]
Whiteboard: [nsbeta2+] 6/1 → [nsbeta2+][6/15]
Unable to reproduce on my Linux build from today, will check Win32 when that build is finished.
Also unable to reproduce this on Windows. The password dialog comes to the front as it should. Can someone verify that this is fixed?
Not an issue any more. Password dialog is modal.
Every single situation is unique. We're talking about the password dialog you get when you ask to fetch mail messages, right? It may be modal, but it isn't given a proper parent (so you can, for instance, close the mail window behind the password dialog). The answer to every one of this class of problem is to give the dialog a proper parent window. This one's probably no different. They really should be assigned to the people who made the dialogs. It might be worth my time to write up about fifty bugs like this and track down who wants to own each of them. Then again, maybe not.
a) cleaning up status whiteboard by marking beta2 minus (6/15 is passed) b) Reading the above suggests this is fixed... if so... please mark it as such so we can get it verified. ...or is the bug partially fixed, but still not really modal? (i.e., it comes to the front, but is not modal :-/ ). Thanks, Jim
Whiteboard: [nsbeta2+][6/15] → [nsbeta2-]
Marking fixed based on my experience and since I created this bug.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
I haven't been able to reproduce the described problem involving password dialog using the jun20 commercial build. Marking verified. Will keep an eye out for any problems, will log new separate bug(s) and provide tracking back to this as a reference.
You need to log in before you can comment on or make changes to this bug.