22720 - Account Wizard should be window-modal, not app-modal

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Account Configuration, defect, P3)

Description

[Jesper Juhl]

If I start the "New Messenger Account Wizard" I cannot continue to surf the net
using Mozilla until I close the Wizard. To be specific, Mozilla freezes
completely until I close the Wizard.

I am using Mozilla M12 Build ID: 1999122023 on a Slackware Linux 7.0 system
(hardware is IBM ThinkPad 600) with kernel 2.2.13 - using KDE 1.1.2 as desktop
envirunment.


- Jesper Juhl - [e-mail]

Comment 1

[Sean Richardson]

At present, the usual reason that the "New Messenger Account Wizard" is
active is becasue no account has been specified yet (This isn't done
at initial profile setup yet), so it makes sense that this Wizard would
be modal with respect to all Messenger and Message Compose windows.
But there is no need for it to be modal with respect to Browser and other
Composer windows. Ideally, this would get fixed for improved User Experience.

On the one hand, the workaround is easy: just finish or cancel the wizard,
but on the other hand, if the user is distracted into doing something else,
and has enough other windows open to obscure the Wizard, the user may not
remember that it was left open, and think that all of the windows in the entire
app are frozen when really the only problem is that a modal window is still
waiting.

Changing Product to "MailNews" from "Browser" and Component from
Browser-General" to "Account Manager" (not sure about the latter).

Comment 2

[Sean Richardson]

Now that the Product is set, assigning to Component.

Comment 3

[Alec Flett]

hmm.. what we really need are window-modal dialogs. But I'm not sure we'll
actually be able to do that.

Comment 4

[Sean Richardson]

If "window-modal dialogs" means dialogs that are tightly bound to, and modal
for, only one window, this appears to be something that Communicator 4.x
(4.7 at least) users will be expecting, and also something already in the works.

Bug 19221, "Dialog Modality added for Bug 10000 causes bad UE bustage", M14,
covers this issue for other dialogs - if the "New Messenger Account Wizard"
is not too different from other dialogs, this bug may be a DUP of bug 19221,
or it may be waiting on a fix for bug 19921.

Quoting from bug 19921:
>* 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.

Comment 5

[Alec Flett]

I'm sorry, but the expected results from bug 19221 are WRONG. 5.x is not a 4.x
clone. in 5.x, we bring up the new account dialog when they have no accounts,
this is different than 4.x behaved, thus the expected behavior is different.

Comment 6

[Ninoschka Baca]

Build 2000010309M13: NT4

I like the Windows implementation in todays build. If a modal dialog is launched
then the parent window is frozen but all top level windows are available.

Steps to reproduce:
1. Launch the Browser (site: www.netscape.com)
2. Launch Mail
3. Select Edit/Account Setup
4. Try to access a Mail menu item (File|New), nothing happens.
5. Switch to the browser using Alt+Tab
6. Go to another site (site: bugzilla.mozilla.org) and it works.
7. From the browser select Tasks|Composer
8. Type some text in the Composer window, it works. Access its menu
items and it also works.

Additional Information:
Mac and Linux behave differently with todays build (2000010309M13)
- Linux: In Mail open Account Setup and it is the only active window. I can
select a top level window and move windows around but nothing works. Selecting a
menu item does nothing, unable to type another website in the URL field.
- Mac: In Mail open Account Setup and it is the only active window. All other
windows are frozen. All top level windows are frozen. I can't even move windows
around as on Linux.

Comment 7

[Stephen Anderson]

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

Comment 8

[Matthew T (active 1999-2002)]

Resummarizing. But I think this should be WONTFIX. Two main reasons.

Firstly, making the Account Wizard window-modal would make a faultless UI 
implementation extremely difficult. Whenever the Wizard was opened, you'd have to 
scurry around disabling all menu items (and toolbar buttons, and keyboard 
shortcuts, and Web page links, and address book items, and ...), in all 
components, where choosing the item would normally result in the creation of a 
new message -- otherwise you might end up with two Account Wizards open, which 
would Not Be Good.

In such a case you could just pop the existing Account Wizard window to the front 
each time, but imagine what would happen if you were a user who didn't realize 
why the Account Wizard kept appearing ...

Click the New Message button in a mail window. The Account Manager pops up. But 
no, I don't want to set up an account now, I'll go and do some browsing instead. 
In the browser window, click on an e-mail link in a Web page. The Account Wizard 
pops to the front. But no, I don't want to do set up an account right now, I just 
want to follow that link on the page! (I haven't realized, of course, that it's 
an e-mail link.) Click on the link again (which I can do, because the Account 
Wizard is modal to the Messenger window, not to the Navigator window). The 
Account Wizard pops up again. Repeat a few more times, with gradually increasing 
levels of annoyance.

Finally, I decide to do set up my account, to get rid of this danged wizard. So I 
fill it out, select Finish, and ... a dozen or so message composition windows pop 
up, one for each time I clicked on the link (they were all waiting for me to 
finish with the Wizard). Yek.

And the second reason is that setting up a new account is an extremely uncommon 
occurrence in normal use (doing Mozilla QA is not normal use). It is also a 
rather complicated task. So I think it's reasonable for the Account Wizard to 
expect the user's full attention (their full Mozilla attention, anyway) while the 
Wizard is open.

Comment 9

[scottputterman]

Mass moving to future

Comment 10

[Alec Flett]

massive reassign of account manager bugs -> sspitzer
please feel free to put me back on the CC if you have any questions/comments

Comment 11

[(not reading, please use [e-mail] instead)]

mass re-assign of account manager bugs to racham.

Comment 12

[Stephen Anderson]

Works for me on Win2K SP1 build 2001050320.

Comment 13

[Ninoschka Baca]

Reopening.

I'm not clear on the resolution of this bug. It appears that the different
platforms still have different implementations. Windows and Mac still work as I
described on 1/3/2001. 

Comment 14

[Stephen Anderson]

I'm sorry.  This bug worksforme in the context of my dup'd bug 24308.  I did not
see what you were trying to do in your 1/3 description.  You are correct, that
behavior has not changed.  Personally, I think the current behavior in that
context is correct.  But, that's just my personal opinion.

Comment 15

[R.K.Aa.]

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

Comment 16

[Stephen Moehle]

I will just summarize what I wrote in bug 114251:

When the account manager dialog is open, the mouse is completely blocked in top
level browser windows, but the keyboard is not.  One can still navigate around a
browser window using the Tab key, type in text areas, and scroll the window
using the arrow keys.

To me this is completely unintuitive.  When this happened to me, I was editing a
bug.  I then opened the account manager dialog to check some settings, came back
to the bug, and continued typing.  When I later tried to use the mouse, I could
not figure out why it was not working.  It took me a long time to figure out
that it was because of the account manager dialog.  I have been using Mozilla
for a long time, and even so I found this behaviour utterly baffling.  It is
even more confusing because the Preferences dialog does not behave this way. 
This dichotomy between mouse and keyboard and between Preferences and Account
Manager dialogs is way too confusing.

My opinion (not that anyone cares) is that the Account Manager should only be
modal to the Mail/News window and not to the browser windows.

Comment 17

[John Levon]

R.K.Aa, I think your last dupe was a mis-dupe (see also bug 116504).
comment 16's points should be a separate bug to the behaviour this
bug is talking about IMHO

Comment 18

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 19

[Stefan Borggraefe]

This bug is WFM. The New Account Wizard only blocks the window it was opened
from. Other windows can still be used while it is open.