Build: 2000031908, MacOS 8.6 The ability to change the Master Password should not be in a submenu of a submenu of the Tasks menu. It should be a button in the Password Manager instead. Reasons: * Doubly-nested hierarchical menus are really, *really* bad UI design. See URL. * It is much easier to explain the purpose of a master password, and the usefulness of setting it, inside a dialog devoted to storing the things which the master password protects, than in a parsimonious menu. * Changing your master password isn't something you're going to do often enough for it to deserve its own menu item. So, make a `Change Master Password' button in the Password Manager dialog, and turn the `Tasks' > `Password Manager' > submenu into a `Tasks' > `Password Manager' menu item.

The layout of the task menu is temporary -- German has promised us a special line in the chrome to access the wallet functions sometime in the future. But accessing it from the signon viewer as well is a good idea. I'll try to get that in before the beta2 freeze (M16).

On second thought, I'm not so sure this is a good idea. The password is shared between single-signon and wallet. So should we also put a button in the wallet editor to change passwords. What about the wallet previewer? It seems like the best place for invoking the change-password function is someplace that is common to both of them. An obvious suggestion is the pref panel in the advanced/password-manager pane. But this should really be UE's call. Reassigning to German.

Yep - what I would recommend: We leave the menu as is, but would not make this the only means of accessign the Master Password. We add a 'bridge' button labelled 'Change Master Password...' to the bottom of the 'Password Manager'pane in prefs. Any future addtion to 'Personal Managers' that will have prefs will hopefully fit into the same prefs pane. (which should then get relabeled 'Personal Managers' just like the Menu) Re-assigning to Steve.

Fix in hand. Will check it in as soon as the tree opens today.

Fix checked in. Files affected are pref-wallet.xul and pref-wallet.dtd.

there's now a "Change Passwords" button in the Forms & Passwords panel in prefs (although there are still issues --see bug 33545). the menu item is [still remains as per german] Tasks > Personal Managers > Password Manager > Change Master Password... verified with the following opt comm bits: linux 2000.03.28.09 macOS 2000.03.28.10 winNT 2000.03.28.09

Ironically, the main thing I was concerned about was the yukky nested submenus, and that's the only part of the bug report which hasn't been fixed. :-)

I happen to agree with you on that one. But that was German's call. Here is my proposal for eliminating the three levels of menus. German, what's your opinion on this? Currently we have: Navigator Mail Composer ----- Address Book Newsgroups Personal Managers Security Manager Password Manager View Stored Passwords Change Master Password Cookie Manager View Stored Cookies Allow Site to Set Cookies Block Site from Setting Cookies Image Manager View Sites that can/cannot Display Images Allow Site to Display Images Block Site from Setting Images Form Manager View Stored Form Data Prefill Form Safely Prefill Form Quickly Capture Data From Form Interview Demonstration ----- Tools History Import Utility Java Console Password Mozilla I would prefer to see: Navigator Mail Composer ----- Address Book Newsgroups ----- Security Manager Password Manager View Stored Passwords Change Master Password Cookie Manager View Stored Cookies Allow Site to Set Cookies Block Site from Setting Cookies Image Manager View Sites that can/cannot Display Images Allow Site to Display Images Block Site from Setting Images Form Manager View Stored Form Data Prefill Form Safely Prefill Form Quickly Capture Data From Form Interview Demonstration ----- Tools History Import Utility Java Console Password Mozilla

Absolutely. And then we wouldn't have the problem of trying to decide whether to call the main menu item `Personal Managers', or `Personal Data Managers', or `Privacy Managers', or `Security Features', or ...

heh! it would be nice to get rid of the Personal Managers parent menu. so, with this recent exchange, shall we reopen this or open a new bug (prolly better, as this seems to be morphing :-)?

Reopening per Sara's suggestion.

Reassing to German to make a decision on the menu change. German, if you agree that we should change the menu as described above, reassign to me and I'll implement it.

This is not a stability blocker for M15 branching... so I'm pushing this to M16

Problem is there is (sorry marketing) a bunch of other useless $$$ stuff sprinkled into the menu which is not in there yet for the Netscape version. I am just worried about the overall length of the menu. Other than that the suggestion is very reasonable. I'll try to get the proposal from PM and work with them to reduce it such that we can have the proposed easier to access menu structure.

[nsbeta2-]

M16 has been out for a while now, these bugs target milestones need to be updated.

nominating nsbeta3

I still much prefer the current implementation which uses "Privacy and Security" as the umbrella term. Reason: that will likely make it understandable for end users what's underneath there without scaring them with a cluttered menu full of 'managers'. That ways it looks both less complex as well as it gives a context what these are for. Clearing nsbeta2.

It might give them a clearer understanding but it will also insure that they will never use features such as wallet because its just too tedious to get to the menu entry.

adding dependency; also adding mostfreq --i know there aren't any dups (yet), but this issue crops up so frequently that i want it easily accessible when i query my bugs.

Yes, I don't care much how understandable it is for the end user if it isn't easily accessible. They only need to learn to use it once, but they will need to access it often. I think we need to reach a better compromise between accessibility and learning curve. Please reassign to me when a UI/UE decision is reached so I can make the necessary change.

Removing mostfreq - this bug does not yet qualify for this keyword under the established criteria. Gerv

adding se-radar to status so that i can find this bug more easily. pls don't remove it [yet], thx.

Marking nsbeta3- while assigned to german.

spam: mass-moving open password manager (single signon) and form manager (autofill) bugs to Terri for qa contact. unfortunately, i cannot cc myself with this form, so feel free and add me if you want to keep me in the loop with any (but, pls not all :) of these... will also go thru 'em meself, a bit later...

If German isn't going to do anything with this bug in 5 month's time, maybe Matthew will. reassigning to him. Give me one clear description of how the Tasks menu needs to be (and maybe some ascii art ;) and I'll give you a patch.

Hmmm, this bug is morphing more and more -- but whatever, here's what I think should happen to the Tasks menu. In general: _Tools ------ {applications} ------------------------------ {application-specific tools} In particular, for Navigator: _Tools ------ _Navigator Ctrl+1 {user's chosen mailer} Ctrl+2 {user's chosen editor} Ctrl+3 {user's chosen chat client} Ctrl+4 --------------------------------------------- _Search the Web ... Shift+Ctrl+F _Bookmarks Ctrl+B _History Ctrl+H U_tilities > Utilities submenu ----------------- _Auto-Fill Manager _Password Manager _Cookie Jar _Java Console _Script Console _Import/Export Brief answers to the `where did they go?' questions for the existing menu items will follow after I reboot (Mozilla is currently refusing to show me the submenus at all).

Ok. Here's where all the items in the old Tasks menu should go, where they're not the same in the new Tools menu: * `Address Book': one of the {application-specific tools} for Messenger, but not for Navigator. (If your chosen mailer is Eudora, having this item in Navigator's menus doesn't make a lot of sense.) * `Personal Security Manager': If someone can explain what this item is for (it doesn't seem to do anything), then I'll find a place for it. * `View Stored Passwords' --> `Password Manager'. * `Change Personal Security Password ...' --> a `Change Master Password ...' button in the Password Manager window (as this bug originally requested). * `Log Out' --> `File' > `Quit'. * `Encrypt Sensitive Information' and `Obscure Sensitive Information' --> /dev/null. This is already in the prefs dialog, and doesn't deserve a more prominent interface (ideally it shouldn't be necessary at all). * `Clear Sensitive Information' --> the Delete key when in the Password Manager or the Forms Manager. * `View Captured Form Data' --> one of three tabs in the Auto-Fill Manager. * `View Sites' --> the other two tabs in the Auto-Fill Manager. * `Interview' --> somewhere on mozilla.org. No-one (*no-one*) is going to bother carrying out the interview, for the same reason that no-one reads the manual before they use an app: they just want to *use* the program, dammit. * `Demonstration' --> somewhere on mozilla.org. * `View Stored Cookies' --> `Cookie Jar'. * `Allow Cookies from this' [sic] and `Block Cookies from this Site' --> the `Always Accept' and `Always Reject' buttons in the cookie confirmation dialog. * All the items in the `Image Manager' submenu --> the `Filters' subcategory of the `Display' category in the prefs dialog. * names of open windows --> the taskbar of your friendly local window manager, or bug 53505 if you are unlucky enough to be on a Mac. Reassigning to Blake. Give this menu the slapping it so thoroughly deserves.

Also note that this bug is now practically a dup of bug 17767.

Make sure you have PSM installed. The `Personal Security Manager' item does do something.

No enabled menu item should ever do nothing, no matter what I do or do not have installed. At the very least, the item should ask me if I want to install PSM.

Matthew: File a separate bug on that to the security crypto team and cc me.

See also bug 67416.

A few thoughts: - address book access does make sense for all apps, as it's not just for mail. People entries are used throughout the product for example for presence information in IM buddy lists which can be used from Navigator. - PSM manages all your certificates (your own and the ones you receive), again used in apps throughout - The interview thingie has been taken out and superseeded by a editable "View stored contents" lists in the Forms manager - I do not particularly care for whether it's Tools or Tasks, although Tools is very win32-esque. Win32 users might expect prefs/options there. - I do care about taking out the Open Windows, that is a regression from what we had in 4.x and we should leave it in. - I also believe the Privacy/Security/Data Entry convenience tools should not be lumped together with JS and Java stuff, I believe they are important enough to warrant their own umbrella term. Under 'utilities' it is virtually guaranteed that a large percentage of users will never touch these.

A few responses: - Mozilla doesn't have buddy lists, and it will not in the forseeable future. So there is no point in having the Address Book available anywhere other than in Messenger. I know of no other Web browser which includes an address book in its menus. - Tools might once have been Win32-esque, but once every Microsoft Mac app included one, it ceased to be so. If Windows users expect the prefs to be there, that's because -- on Windows -- the prefs *should* be there. - Taking out Open Windows isn't a regression, it's making Mozilla simpler and more consistent with the rest of the OS. Outlook Express for Windows doesn't give me a list of the windows which I have open in Opera, or vice versa. There is no need to: it's a job for the OS, not the app. Except for Mac OS (which is covered by bug 75546), window managers list open windows quite well enough by themselves. - I don't believe that having `Privacy/Security/Data Entry convenience tools' (what logic groups *those* together??) in their own submenu will make them any more accessible -- if anything, it will make them less accessible, since users will no longer see them when they go for the other items in my proposed `Utilities' submenu. Ideally, Web users wouldn't have to deal with any of that stuff at all ...

See also bug 102592, "Please make Tasks > Tools a toplevel menu".

morse, aren't you doing menu reorg type stuff? If not, send back.

Yes, the window list needs to go away, and the "managers" need to be more accessible, they're useless how deep they're buried... I can get to them through prefs quicker: alt-e, e is alot faster then alt-t, p, c, v or trying to actually navigate that mess with a mouse. The stuff in image manager is useless. You VERY rarely want to block images from the current server, as most things you want to images are eaither third party, or from a differant host (static instead of www, etc). Image manager should launch the viewer, which would have a manual entry textbox. If you really want to block an image your seeing, it should be in the context menu. There, image manager is down to 1 item. Password manager: reset/change password, and obscure/encrypt do not belong in the menus. They require a little explaination, and aren't used much (er...EVER, for 98% of users). Log out is debateable... (just close mozilla, alot more obvious and failsafe, but take it out and down to one item there too (view stored passwords). As far as the top entries in the menu... I don't care eaither way, but I didn't see it mentioned address book would be useful in the browser for web mail, or sending greeting "cards" (ugg, my parents love those dumb things). As far as mpt's suggestion on using chosen editor/mailer/chat program there, I don't think we should be turning Mozilla into some generic application launcher. I don't install mailnews or chatzilla at all and never plan to, so I'm quite content with those entries just not appearing. I launch my mailer with 'm<enter>' (short for mutt) from the command line. I don't see why I'd want Mozilla to do that for me. Some of the Tools (well, History at least), would be nice in the main tasks menu. I tend to just hit ^H anyway, though.

Moving to 1.0 because the bug it depends on (bug 108099) has been moved to 1.0. And if that bug is fixed late in the 1.0 cycle, this one won't go in until 1.1

Nav triage team needs info from UE: is this work covered in the menu spec we all discussed in PixelJockeys, and agreed to?

Nav triage team: yes (although it's now called tools menu not tasks, and some details may not be finalized, however the goal will be to reduced submenus in any event)

thanks - nsbeta1+

morse, have you already begun working on this, or can I take it? I'd hate to see this get cut.

No, I haven't done anything here yet. I've been waiting for a final spec from Marlon. It's on the landing plan. If you want it, and you have the time, then go for it.

The spec <http://www.mozilla.org/mailnews/specs/proposals/MenuFrame.html> is nearly final, will be discusse at PixelJockeys next week.

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

-> me As I understand it, http://www.mozilla.org/mailnews/specs/proposals/MenuFrame.html is supposed to now be complete. But I don't see how it can be deemed complete without most of the accesskeys specified...

And could someone who was at the meeting please explain this to me: "1. File Menu. "New <component window>" is the first menu item, plus the first menu item in New flyout menu. Remove it as first menu item and only have it as first menu item in New flyout menu. Top items in New flyout are specific to that app. Items below the splitter are applicable to other apps. Pixeljockeys 3/20/02. Agreed to give this a try. If there are problems, will re-evaluate." With this change, there is no quick way to open a Navigator (or any type of) window anymore (Tasks > Applications switches windows once you have 2 open). I think this is a really bad idea, and apparently others at the meeting did too. What does "if there are problems" mean? We're going to ship to the world and if people complain, we'll reconsider? That doesn't seem good enough to me for a menu item with such a high frequency of usage.

I'd like to attach a patch for this but I'm getting mixed messages from people who were at the meeting. Is http://www.mozilla.org/mailnews/specs/proposals/MenuFrame.html the final spec or not? Since it was apparently updated Friday, I'd guess yes, but it still lists Work Offline under Tools and I was told that that was going to stay under File.

That spec currently has a mod date of 2AM GMT on March 22, which is well before Friday's PJ meeting. I think UE has not yet updated it to reflect the latest decisions; which is quite understandable considering they were made in a late Friday afternoon meeting.

Spec hasn't been updated yet. Pixeljockies meeting was late friday. I'll be finishing up the spec based on the meeting and hopefully get it posted to mozilla shortly.

dup'ing against bug 32502 since both are nsbeta1+ and cover the same menu work (but that one's more general) *** This bug has been marked as a duplicate of 108099 ***

Verified Duplicate