23095 - need a toolbar for wallet functions.

Status: VERIFIED FIXED

(Toolkit :: Form Manager, defect, P3)

Description

[Stephen P. Morse]

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.

Comment 1

[german]

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?

Comment 2

[Matthew T (active 1999-2002)]

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

Comment 3

[sairuh (rarely reading bugmail)]

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!

Comment 4

[german]

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.

Comment 5

[Eli Goldberg]

It's all yours... ;)

Comment 6

[Stephen P. Morse]

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.

Comment 7

[german]

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

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 9

[Tim Hill]

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.

Comment 10

[Stephen P. Morse]

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

Comment 11

[Matthew T (active 1999-2002)]

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.

Comment 12

[sairuh (rarely reading bugmail)]

since this tracks several issues, adding meta.

Comment 13

[sairuh (rarely reading bugmail)]

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

Comment 14

[german]

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?

Comment 15

[Blake Ross]

sure, I can help.

see also bug 48860

Comment 16

[Blake Ross]

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.

Comment 17

[Stephen P. Morse]

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

Comment 18

[Marcia Knous [:marcia]]

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

Comment 19

[german]

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'

Comment 20

[Stephen P. Morse]

Attaching patch that implements form-manager toolbar.

Comment 21

[Stephen P. Morse]

Attachment: Implements form-manager toolbar

Comment 22

[german]

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.

Comment 23

[Paul Chen]

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

Comment 24

[Stephen P. Morse]

cc-ing alecf for a super-review.

Comment 25

[Blake Ross]

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

Comment 26

[Alec Flett]

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.

Comment 27

[Blake Ross]

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

Comment 28

[Stephen P. Morse]

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.

Comment 29

[Stephen P. Morse]

Attachment: same patch but using removeAttribute as requested

Comment 30

[Stephen P. Morse]

Fix checked in

Comment 31

[Alec Flett]

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.

Comment 32

[Alec Flett]

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?

Comment 33

[Alec Flett]

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

Comment 34

[Stephen P. Morse]

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.

Comment 35

[Stephen P. Morse]

Attachment: changing class on buttons

Comment 36

[Paul Chen]

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

Comment 37

[Stephen P. Morse]

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.

Comment 38

[Blake Ross]

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

Comment 39

[Stephen P. Morse]

Patch to "change class on buttons" checked in.

Comment 40

[Hixie (not reading bugmail)]

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.

Comment 41

[Christopher Blizzard (:blizzard)]

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

Comment 42

[Stephen P. Morse]

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

Comment 43

[Blake Ross]

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

Comment 44

[Alec Flett]

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.

Comment 45

[Mike Pinkerton (not reading bugmail)]

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.

Comment 46

[Eugene Savitsky]

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?

Comment 47

[Matthew Tuck [:CodeMachine]]

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.

Comment 48

[Stephen P. Morse]

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.

Comment 49

[Mark Olson]

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.

Comment 50

[Stephen P. Morse]

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.

Comment 51

[Stephen P. Morse]

Attachment: patch to fix bustage

Comment 52

[Stephen P. Morse]

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

Comment 53

[Matthew T (active 1999-2002)]

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.

Comment 54

[Hixie (not reading bugmail)]

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

Comment 55

[Tim Larson]

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.

Comment 56

[Stephen P. Morse]

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.

Comment 57

[Blake Ross]

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

Comment 58

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 59

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 60

[Stephen P. Morse]

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

Comment 61

[Stephen P. Morse]

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

Comment 62

[Terri Preston]

Verified