A rather cumbersome bug (13022) had been opened on required UI features. Almost all items in that report have now been addressed and the report has just been closed. The only outstanding items are 12, 13, and 14 which have to do with activating certain functions from a line in the chrome and an about-me selection in the task bar. These items are repeated here since the other report is now closed. 12. Activate the following functions from a line that German will be adding at the top of the chrome when a form is detected (this line will here-after be referred to as the "German line"): Wallet Prefill Wallet Capture Change Database Key 13. Activate the following functions from an "about me" selection that will appear on the task bar (if the "about me" does not materialize, then activate them from the menu somewhere): Change Database Key (note that this appears on the German line as well) Present Interview Form Display Wallet Contents Display Logins Display Sites for no-preview formfill Note that the last two items both bring up the same viewer (i.e., the single signon viewer) but they differ in which tab is initially displayed when the viewer comes up. 14. Activate the cookie viewer from the preference menu.

I understand most of these will be past beta (according to kevinyen), but I will accept and fill in the approriate spec information together with Ben and others. Ben have you looked at the current spec and made some progress with the frontend implementation?

`About me' should not, repeat NOT, appear on the taskbar. It is only going to be used once in a blue moon, and will be just clutter the rest of the time. Stick it in the Tasks menu instead. And a word on the German line: the architecture for this should be implemented generally -- some sort of `temporary toolbar' widget -- so that the same widget can be used elsewhere later (for `Find on this page', for example).

reassigning qa contact to self and updating component. eli, if you'd rather keep this bug, go ahead and take it back, but pls add me to the cc list. thx!

Actually I reommend it appears on the taskbar in swince once live profile switching is introduced past 5.0 it will be used at lot ( as in profile for work, for home etc). I don't want to have to change locations of this control, better introduce it now and then leave it there. I also believe privacy is going to be huge issue for 5.0. Auto-fill of forms and sign on screens is only going to be successful if control of these features is *very* accessible to the end-user.

It's all yours... ;)

German, I followed everything you just said about privacy going to be a huge issue for 5.0 and that autofill is going to be sucessfull only if it is very accessible. And I of course agree with all that. But then I didn't understand why, at the same time that you said all that, you also changed the target milestone from M15 to M20.

Ok lets see where we are today on this bug: 12) We still would like to implement the transional toolbar, although I will not be able to do this. We should look for engineering help here, I will see whether I can get andreww who is heloing out with UI engineering to help with that transitional toolbar 13) since we are cutting left and right to make the ship date, having that extra taskbar item maybe something we should consider for past Nsbeta6 14) this portion is fixed, the cookie view is now accessible from prefs

This is a legitimate use for the taskbar. I wish that the commercial taskbar didn't have so much utter crap in it that the more useful items were obscured.

I also need a transitory toolbar for the LINK tag (Bug 2800). But I just need to know where it should be placed and what it should look like (see my comments and concerns in Bug 42438). I could probably add the wallet form buttons while I'm at it.

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

Ok, as suggested by Morse, copying my suggested spec for the Forms Toolbar from bug 48993 to here (with slight modifications). Whenever {focus is in a form element} AND {the form-filling preference is set to `true'} AND ({the form contains at least one non-password field} OR ({the form contains at least one password field} AND {the password capture preference is set to `true'})), a toolbar should be displayed at the bottom of the content frame. If necessary, following the showing of the toolbar, the content frame should be scrolled so that the form element with focus is still visible. Suggested UI for the toolbar: ++-----------------------------------------------------------------+ || ( Form Options ...) ( Remember This Form ) ( Fill In Form ) | ++-----------------------------------------------------------------+ `Form Options ...' is enabled: * all the time. `Form Options ...' does the following: * opens the Forms Manager dialog. `Remember This Form' is enabled: * all the time. `Remember This Form' does the following: * saves all non-password data from fields in the current form (overwriting existing saved data, if applicable) * if the capture passwords preference is set to `true', saves all password data from the current form as well (overwriting existing saved passwords, if applicable). `Fill In Form' is enabled: * if there is existing data stored for this form. `Fill In Form' does the following: * fills in the form with the saved data * if the capture passwords preference is set to `false' and there is at least one password field in the form, gives focus to the first password field in the form * otherwise, gives focus to the first submission button in the form, if there is one * otherwise, gives focus to the first field in the form.

since this tracks several issues, adding meta.

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...

The autofill-expanding-toolbar is something we should seriously consider for NS 6.5 timeframe. any body willing to help Steve with the UI engineering part?

sure, I can help. see also bug 48860

Matthew's 8/15 proposal is good. I don't see any reason why this needs to be assigned to a UI designer any longer, so giving this to morse.

This bug has morphed a bit. Changing summary line to reflect what it's currently asking for.

Netscape Nav triage team: this is a Netscape beta stopper.

Yep would really like to see this materialized for the next commercial and mozilla releases. mpt's design is also what i had in mind, with the addition of potentially pointers to assistance (about autofill, notes on privacy or some such, TBD by information design people), if this doesn't clutter up the main 'raison d'etre'

Attaching patch that implements form-manager toolbar.

This is great! I cannot review this patch from engineering perspective as I am not an engineer, but I think it would be great to check this in as is (as we already talked about the concept being very useful) and look at it from a UI design perspective and make UI tweaks as needed once it is checked in. You should prob. get a technical review from a person more technical then I am.

Patch itself looks ok. I'm not sure about hiding/showing the toolbar on a per page basis (assuming I understand the feature correctly). I would rather see the toolbar items "disable" rather than having the toolbar appear and disappear according to the content of the current web page, but that's UE's call. Just my $.02. r=pchen

cc-ing alecf for a super-review.

This is neat. Thanks for doing it, morse. Nit: + formToolbar.setAttribute("hidden", "false"); I think removing this type of attribute is typically preferred over setting to false. No need to attach a new patch or anything. cc'ing Alec for sr

yes, change the setAttribute("hidden", true) stuff to removeAttribute("hidden") - there are a few places you do this with that, sr=alecf as a side note, someday I'd really like to see the wallet stuff moved into a dynamic overlay so that it's not cluttering up navigator.xul and friends.

Alec: http://bugzilla.mozilla.org/show_bug.cgi?id=31967

Thanks for doing the r= and sr= so quickly. Have made the requested change and will check it in as soon as the tree opens. For archival purposes I'm attaching a modified patch that has the requested change.

Fix checked in

I just updated and I don't see any buttons on the toolbar... not to mention the toolbar is huge (almost as big as the main nav toolbar) I'm thinking this thing should go just in the content area or something, instead of over the sidebar as well.

in fact, given how obtrusive it is right now, can we turn it off by default and people like german who want to take a look at it can turn it back on by the menu?

so upon further investigation, it seems that the button-toolbar-1 class makes the buttons tall, but contain no text. if I use button-toolbar-3, they look like real buttons. can someone attach a patch that changes the class to button-toolbar-3 and I'll sr= this? otherwise, I think we need to back this out...

Thanks, that is an improvement. I didn't realize that we had two classes -- one that makes the entries look like menu items and the other like buttons. Attaching patch as you suggested. I don't understand your comment about not seeing any text at all. On my windows box I definitely see the text in both cases but it does look better inside a button.

r=pchen on the change to "button-toolbar-3"

Now for the bad news. The test for determining if the prefill button should be enabled involved calling into the wallet module and that caused the module to be initialized resulting in some early bloat that wasn't there before. Also possibly some leak. Therefore I just removed that test and the buttons are always enabled whenever the form-manager toolbar is displayed. Still waiting for the super-review from alecf so I can check in the change that he recommended.

Alec explicitly gave sr= to change the class earlier on IRC, because he had to leave.

Patch to "change class on buttons" checked in.

BTW, are we sure we want this added to navigator.xul? I would have thought since wallet was supposed to be an optional extension, it would make more sense to have it as some sort of overlay or something.

Christ, that's ugly. UI elements that appear and disappear are bad plus they don't fit in with the rest of the UI. They are raised buttons on a toolbar where the other toolbars don't use that kind of relief. Plus, it's going to make my wife nuts ( and therefore make me nuts ) since she doesn't have enough vertical space on her laptop as it is with Mozilla. Is there a way to turn that off by default until it gets cleaned up? Plus, View Saved Data hangs the browser on Linux. http://bugzilla.mozilla.org/show_bug.cgi?id=64323

Your wife's problems can be solved by going to view->toolbars and turning off the form toolbar.

Changing the class was not the correct fix. These buttons now look completely out of place in Classic.

Can we please turn this off by DEFAULT until we have it looking better? It's ugly (and it's not blizzard's wife's problem, it's mozilla's problem) and many, many webpages have forms on them, including: http://home.netscape.com/ http://www.mozilla.org/ http://www.yahoo.com/ etc - this basically turns on for every popular web page, effectively turning it on permentantly.

this is very jumpy and distracting, especially over slow connections since the toolbar doesn't appear/disappear until the page finishes loading, which can be long after the user begins to interact with the page. I start reading, then sometime later the page loads and everything jumps suddenly, making me lose where i am. i think this idea needs some more thought.

It is a better idea to make a new menu for this in right-click menu... Should we open a new bug for this RFE?

I would expect that this and other toolbars like it (eg the HTML <LINK> bar) should have toolbar on/off switches like the other toolbars. When on, they would appear if needed. When off, they would never appear. Perhaps the menu item should say "Wallet Toolbar, If Needed" or something. Is this appearing at the top of the window? I would expect that if these sorts of bars appeared at the bottom the window wouldn't jump.

Eugene, these features already exist in the right-click menu and also in the edit menu. The problem was one of discoverability. Mathew, there is a toolbar on/off switch for it in the view menu, just as there is for other toolbars.

This checkin also causes several new javascript strict errors in navigator.js. Also, there is some suspicious code in setFormToolbar such as: var formToolbar = document.getElementById("FormToolbar"); if (!formToolbar) { formToolbar.setAttribute("hidden", "true"); return; } where formToolbar is referenced after we know it is invalid, and line 1671 where formToolbar is referenced before being declared.

I guess I was a bit overzelous here with my hiding code. Attaching a patch to fix this. Treating this as a bustage (introduced javascript errors) and checking it in the fix immediately.

Actually the above three comments (Mark Olson's observations, my follow-up comment, and my patch) belong in bug 64355 and not here.

I think we may be about to discover that this whole autofill thing is a waste of time -- because it may be impossible to have a UI for it which is both discoverable and non-intrusive, and it may not save enough time (when compared to auto-completion of individual form fields, or cookies set by the form author) for users to bother with it. However, the following changes may (combined) make the interface acceptable: * putting the toolbar at the bottom of the viewport, rather than the top, so that it does not vertically scroll the content when it appears/disappears; * animating the appearance/disappearance of the toolbar (by scrolling it up from the bottom of the viewport) over 0.5 seconds (like paragraphs after the caret do in MS Word when you press Enter), so that it does not startle the user; * only showing the toolbar for forms which might usefully be saved/prefilled, i.e. forms which have ~3 or more text fields in them; * including a `Show next time' checkbox at the right end of the toolbar, which (if unchecked) turns the toolbar off permanently. If anyone wants to file bugs on the above, post the bug numbers here.

(mpt: good ideas; for the first I assume you really mean "bottom of viewport when the principle text direction is top-to-bottom and top of viewport when the principle text direction is bottom-to-top" though, right? Not that we support bottom-to-top yet, but it's worth making the architecture work with it. Or would that be too confusing for multi-lingual readers? Appearing and disappearing top and bottom... Also, it would still jerk pages that are vertically centered, of which there are a lot... I guess I'm still not convinced we want autohiding. But then I've never liked autohide. Maybe we can have the existing toggling pref be three-way? Always, when applicable and never?) I still think it would have been nice to have a thought-out spec before this was implemented...

Hixie said: > Maybe we can have the existing toggling pref be three-way? Always, > when applicable and never? Yes, yes, yes! I said the same thing for bug 2800. It's the only way I see to implement the feature, yet address the concerns regarding that implementation (reduction of viewport vs shifting content). Give the choice to the user.

MPT's points are well taken. In fact, the hidding of the toolbar by default is only temporary (at least that was my understanding) until some of the objections to the toolbar are ironed out. However that's a catch-22, because how will be know what those objections are if it's hidden and nobody complains. In any case, I'm reopening this bug as a reminder that we want to have this non-hidden by default.

> I still think it would have been nice to have a thought-out spec before this > was implemented... Yes, I completely agree. Maybe we should wait until Matthew can do a spec before going any further on this. I agree with Matthew that we're going to find that this is all just going to confuse and slow down the reader, for a feature that was meant to save them time. IE's minimal but powerful autofill capabilities are popular not because they have a bunch of dialogs, highly complex schema for field matching, a blurry distinction between autocomplete and autofill, and a toolbar on steroids. I see that bug 60861 has been passed to nobody. But I digress (that's bug 48860).

Steve, please do not make modifications to Navigator without consulting me first. The modifications made are in their current form not acceptable from a code or UI perspective. Specifically: - Wallet is an extension. It must abide by the drop in component rules followed by other components in the extensions/ directory. The pre-toolbar wallet FE code did not abide by these rules but it was a bug. I do not appreciate exacerbating a problem however. Navigator's standards are higher. - The wording used is poor. I prefer mpt's suggested wording. - The buttons are out of place in both themes. They should use the same button styles as the composer toolbar buttons. - I question the need for a completely new toolbar for access to this feature. I do not see the View Saved Data option as a high usage item, and form data saving should be implicit, like IE5/Win. At the very least, the code must be removed from Navigator Immediately and relocated into dynamic overlays that live in extensions/wallet . Please look at how Mail/News overlays menuitems and other UI elements into Navigator and follow their example. The UI and appearance discussion can continue here.

More UI notes: I agree with alec in that it should be over the content area only, and with mpt in that it should scroll down, like the IE5/Mac auction assistant. Please visit an auction listing on ebay using IE5/Mac to see this in action. I think this could be possible with some inventive hacking. (also: I imagine that the link UI toolbar might share this style of implementation.)

Moving the request for 'separate overlay for form-manager toolbar' into a new bug report. Namely bug 64508.

Fixed. All code for form-manager toolbar is now in place and is on by default. But, alas, all the form-manager toolbar code has also been commented out. Code is part of the patch for bug 31967

Verified