Closed Bug 23095 Opened 21 years ago Closed 20 years ago

need a toolbar for wallet functions.

Categories

(Toolkit :: Form Manager, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: morse, Unassigned)

References

Details

(Whiteboard: [note to self: need eng help])

Attachments

(4 files)

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).
Blocks: 7530
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!
Component: UE/UI → Autofill
QA Contact: elig → sairuh
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.
Target Milestone: M15 → M20
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
Whiteboard: [note to self: need eng help]
Target Milestone: M20 → M18
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.
Blocks: 48860
since this tracks several issues, adding meta.
Keywords: 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...
QA Contact: sairuh → tpreston
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.
Assignee: german → morse
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Summary: UI issues for single-signon/wallet → [w]UI issues for single-signon/wallet
This bug has morphed a bit.  Changing summary line to reflect what it's 
currently asking for.
Summary: [w]UI issues for single-signon/wallet → [w]need a toolbar for wallet functions.
Summary: [w]need a toolbar for wallet functions. → need a toolbar for wallet functions.
Whiteboard: [note to self: need eng help] → [w][note to self: need eng help]
Netscape Nav triage team: this is a Netscape beta stopper.
Keywords: nsbeta1
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
OS: Windows NT → All
Hardware: PC → All
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
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Keywords: meta
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
> 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.
Whiteboard: [w][note to self: need eng help] → [note to self: need eng help]
Status: REOPENED → ASSIGNED
Target Milestone: M18 → mozilla0.9
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
Status: ASSIGNED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Verified
Status: RESOLVED → VERIFIED
Assignee: morse → nobody
Product: Core → Toolkit
QA Contact: tpreston → form.manager
Target Milestone: mozilla0.9 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.