63320 - Double clicking on text field to bring up a list of possible entries

Status: RESOLVED WONTFIX

(Toolkit :: Form Manager, defect, P3)

Description

[Stephen P. Morse]

There is code in contentAreaClick.js for prefilling a single textfield when it 
is double clicked on.  That file also contains code for bringing up a list of 
possible values in the case that there is more than one.  However there were 
some problems with bringing up the list, so that code is commented out.  The 
consequence is that if there is more than one value, the first value will be 
prefilled and the user has no choice about that.

This bug report is to get the commented-out code working properly.

(Note: this is an offshoot of bug 48982)

Comment 1

[Azrael AOD]

Just interested in following progress :)

Comment 2

[Marcia Knous [:marcia]]

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

Comment 3

[Stephen P. Morse]

Attaching patch.

Decided not to implement it with double click after all.  Rather, the menu comes 
up when you single-click on a textfield for which there are saved values.  And 
that means that we no longer need the field to be automatically prefilled with a 
double-click -- it's simpler to do a single click and then select the value you 
want from the pop-up menu that appears.

The changes are as follows:

rdf/content/public/nsIXULPopupListener.h
  define "prefill" popup type
rdf/content/src/nsXULAtoms.inc
  define atom for "prefill" popup type
rdf/content/src/nsXULPopupListener.cpp
  "prefill" menu to close on keydown
rdf/content/src/nsXULElement.cpp
  install key-down handler for "prefill" menu, remove assert
layout/xul/base/src/nsPopupSetFrame.cpp
  don't install keyboard navigator for "prefill" menu

xpfe/browser/resources/content/navigator.xul
  add elements for "prefill" menu
xpfe/communicator/resources/content/contentAreaClick.js
  removed doubleclick code for prefilling
xpfe/communicator/resources/content/prefillList.xul
  xul file for "prefill" menu (new file)
xpfe/communicator/resources/content/nsPrefillMenu.js
  js file for "prefill" menu (new file)
xpfe/communicator/jar.mn
  installs the two new files into the jar file

Comment 4

[Stephen P. Morse]

Attachment: Patches for changed files

Comment 5

[Stephen P. Morse]

Attachment: xpfe/communicator/resources/content/prefillList.xul (new)

Comment 6

[Stephen P. Morse]

Attachment: xpfe/communicator/resources/content/nsPrefillMenu.js (new)

Comment 7

[Matthew T (active 1999-2002)]

Single click is correct, but only if the control already has focus. (So a 
double-click, which Blake reported as IE's behavior in bug 48982, is equal to 
focusing the field and then single-clicking it.)

I'm not that good at reading JS code, and I can't try the patch myself, but 
there are several things which appear to be wrong with it (these are partly 
based on discussions I had with Blake in IRC):
* you should not create a new XUL atom, you should use the existing auto-fill
  widget (as used in Navigator's address field, and in the message composition
  window);
* the menu should only show items which begin with the text that is already in
  the field (so you can filter the items by typing the first couple of
  characters of the string you want to use);
* it's not clear whether the items in the menu are sorted alphabetically (they
  should be).

For bonus points, make these changes to the autofill widget (these would not be 
necessary for this bug to be marked fixed, but should be implemented 
eventually):
* make it resizable (no matter whether it's used here in HTML forms, or in the
  address field, or wherever) -- Ben Goodger has the code for doing this;
* allow an item to be deleted from the menu by highlighting it and pressing
  Backspace or Delete.

Comment 8

[Stephen P. Morse]

I have to disagree with many of the points you are making.

1. Why should single click work only if the element has focus?  This requires 
the user to know (1) that there might be some values saved for this field and 
(2) that by clicking on it again the user can make the list of these values 
appear.  The way I have implemented it is that when the user clicks on a field 
to start to fill it out, he will suddenly be presented with possible values to 
use.  He needs to know nothing special and he gets a pleasant surprise.  The 
next step is to make the menu popup when the user tabs to the field (instead of 
clicking on it) but I can't tackle that until after this gets approved and 
checked in.

2. The existing auto-complete (it's not autfill) widget is for a xul element 
which the navigator's address field is.  In the current case, the element to be 
filled in is an html element appearing in the website's content, so the existing 
auto-complete widget is not applicable.

3. The menu that I have implemented is not for autocompletion but rather for 
autofilling.  Before the user ever types in any characters, the menu should 
appear and show him some possible choices.  Once he starts typing characters, he 
has effectively told us that he doesn't want to use the saved choices and so the 
menu should disappear.  Keep in mind that in the vast majority of cases there is 
only one saved value for each schema, so the metaphor of autcomplete doesn't 
really apply here.

4. No, the items should not be alphabetised but rather should be sorted by 
most-recently used.  I took great pains to always keep the list ordered that 
way.

Comment 9

[pnunn]

The patches look ok to me.
The design seems simple, straightforward and intuitive.
r: pnunn

Comment 10

[Blake Ross]

No, this is not okay.  Pam, there are clearly many points of contention about 
this patch, and an ongoing UI discussion.  Why would you go and review it 
without addressing any of the open issues?  If Netscape 6 isn't the best 
testimony to what happens when you implement first and consider usability later 
then I don't know what is.  Please read 
http://mozilla.org/hacking/reviewers.html about reviewing, especially the parts 
about examining context and looking at the big picture.  I already see some 
issues just from glancing at the patch (e.g. not following convential naming 
schemes -- prefillList.xul instead of prefillListOverlay.xul).

Morse, please do not go and find another reviewer because I didn't respond in 
one day (you first e-mailed me yesterday), especially during the holiday 
period, when hardly anyone is around.  Module owner should be ready and willing 
to listen to criticism about patches.  Why are you so anxious to check this 
in?  I appreciate your hard work, but I would much have this done correctly the 
first time then to infinitely split off more bugs until it's done right (bug 
48860).

On to the points at hand...

(1) Surprises are hardly ever pleasant in user interfaces, and this is probably 
no exception.  Clicking once in a textfield should focus it.  Having a menu 
drop down every time I did that would soon get annoying...

(2) This sounds like an "it's not currently possible" excuse, not a "it 
can't/shouldn't be done".  Autocompletion should be one generic service that 
takes a generic resources (e.g. an rdf datasource) and handles the rest on its 
own.  I would be glad to help do this; I've even been considering starting an 
Autocompletion project, along with the help of others.  Matthew has agreed to 
provide UI specs.

(3) Why has he effectively told us that?

> Keep in mind that in the vast majority of cases there is only one saved value 
> for each schema, so the metaphor of autcomplete doesn't really apply here.

Why is this, when IE helpfully provides many choices for each?  This is a 
problem.

4. I appreciate your effort to allow chronological sorting, but that's not 
justification for doing it.  The ultimate goal here is maximum usability for 
the user, not less work for the developer, as harsh as that sounds.  If I'm 
trying to find an item in a list (and you are, hence the whole point of this 
feature), which is going to help me more -- an alphabetized list, or a list 
sorted by most recently used values?  Chronology is irrelevant in this case.  I 
might need to prefill a value that I last filled in last year, or yesterday.

No, I'm not just going to say "r=blake" and split off 3 more bugs to get this 
right again. Autocompletion and form manager and password manager got in their 
current states (not following any spec, inconsistent implementations, infinite 
user interfaces, unreusable and non-generic modules) by doing exactly that, by 
rushing to get things checked in, by an unwillingness to partake in any kind of 
extended usability discussion, and by a general feeling of anxiety that has 
gotten in the way of the ultimate goal: what's best for the user.  I would 
expect more from two module owners.

Comment 11

[pnunn]

gee, I didn't realize we had to clear all 
code changes through the great Blake Ross?
I thought maybe some other mozilla people might
be able to have opinions, too.
-p

Comment 12

[Blake Ross]

Well, gee, considering I was asked *yesterday* to review this, only to find 
that I was brushed aside today for another reviewer who hasn't even taken part 
in the discussion here?  Yes, you generally clear code changes with the person 
you asked to review.  I also filed the initial bug.

Yes, I'd love to hear input from other people in the community.  That's why 
I've been discussing it with them for hours on IRC.  That's why I said "let's 
slow down and work this out."  That's why I asked Matthew two write a spec for 
this.  But you, apparently, do not, since you went ahead and reviewed this 
anyways.

One of the main reasons I'm so angry about this is that you did a similar thing 
in bug 62727 -- namely, you ignored the ongoing discussion in favor of 
reviewing the patch anyways.  You also stopped to wonder aloud why any time was 
being spent discussing these wording changes.  For someone who has expressed an 
interest in hearing the opinions of other contributors, I'd love to hear your 
explanation for why you went and reviewed a patch without acknowledging such 
inpute.  That patch was highly trivial and non-urgent.  Perhaps such anxiety 
was acceptable in the pre-6.0 days because of the tight, hurried schedule, but 
it's a new release cycle for Netscape now.  That sets a bad precedent.

Renominating for beta1 since this can't really be a beta stopper (new feature), 
and I'd rather spend more time on this to get it right.

Comment 13

[Brendan Eich [:brendan]]

Play nice, kids.

First, talking about things in a bug (or a newsgroup first, if the discussion is
too free-wheeling and large to fit in an unthreaded format with a six-line
textarea for data entry!) doesn't slow anyone down significantly from "shipping"
(else the ship date better be tomorrow or in a few days), and should not be a
cause for anxiety or rancor.

Ok, my comments:

We are trying to unify HTML, XML, and XUL content sinks and DOMs, so I don't
think morse's reasoning in objection (2) leads us in the right direction. We
should share mechanism and reduce footprint here, if at all possible, by reusing
existing autocomplete machinery for this autofill multiple-choice case.  Cc'ing
hyatt and waterson for advice.

What's more, if there are multiple possible completions for autofill, based on a
prefix of one or two characters that I have typed, I might well like to see the
remaining choices narrowed down as I type.  This is exactly the problem that the
existing autocomplete machinery implements.

I do think morse's MRU algorithm could turn out to be handier for common cases,
and not less usable than a lexicographic sort for very short (2-4? mpt help me)
choice-lists. Should the algorithm be MRU for short lists, lexicographic sort
for long ones?

/be

Comment 14

[pnunn]

I disagree with blake.

My main focus is developing a usable software product
in a finite amount of time, not discussing how many
different ways we can reword an already understandable,
reasonable user message.

-pn

Comment 15

[Stephen P. Morse]

This bug was nominated as nsbeta1 by the triage team.  See knous' comment on 
12-21.

Comment 16

[Blake Ross]

I was renominating it the only way I know how to.  I think they made a mistake, 
since this is a new feature...

Comment 17

[Alec Flett]

a side comment (hopefully not too much fuel for this fire) since I was asked to
sr= this - I don't understand why we're inventing a third type of popup in C++..
why can't there be a XUL solution to this? I can't sr= this until we hear back
from hyatt.

Comment 18

[Peter "jag" Annema]

Heh, just collided with alecf, who apparantly was struck by a similar thought.

This sounds like you're re-inventing the combo-box, but without the drop-down
arrow.

Comment 19

[Matthew T (active 1999-2002)]

It may be that a XUL solution is not possible until XBLified form controls are 
developed well enough to be used by default. But that's not my area.

Now, back to the UI problems. First, invocation. Like Blake said, surprises are 
almost always bad in a UI. A single click to open the menu is unacceptable 
because it would obscure other elements in many fields, and leave novice users 
with no obvious way of hiding the menu. For example, if I wanted to change the 
`Summary' field of this bug report but clicked in the `URL' field by mistake, 
the `Summary' field would get covered with a menu of the various URLs I had 
entered for bugs in the past. This would be ok on a second click (since I'm 
clicking again, I'm obviously expecting something extra to happen, and I'm 
prepared to do a third click to hide the menu again), but on a first click it 
would be highly annoying.

Secondly, I think Steve is trying to make a distinction between `autofill' and 
`autocomplete' where such a distinction means nothing to the user. The menu 
should only show options that begin with the characters already entered in the 
field; when the field is empty, this is obviously equal to the total collection 
of options. I would be surprised if the number of options was *usually* only 
one; for Bugzilla, on-line reference tools, and so on, I would expect it to 
offer more than one, and this may mean that the autofill algorithm is being too 
`smart'. For example, what if I want to look up the same word in a number of 
different online dictionaries? Or if I want to look up the same title in a 
number of different online bookstores? Or if I want to do a Web search to find 
reviews of a book that I couldn't find reviewed in any online bookstore? Is 
this menu not going to help me, because the fields in each are considered to be 
in different schemata?

And finally, ordering. Chronological ordering would perhaps be marginally 
better than alphabetical ordering, *if* you were sure that the menu would never 
have more than 6~8 items in it -- only because it would require fewer 
keypresses on average to select the item you wanted, not because it would be 
any easier to scan. But since the menu will often have more than 6~8 items (in 
the search field of your favorite Web search engine, for instance), it would be 
best just to use alphabetical order consistently. (Using two different ordering 
schemes, depending on the length of the menu, would be more confusing than time-
saving.)

Comment 20

[Stephen P. Morse]

In reply to Mathew Thomas' comments:

> surprises are almost always bad in a UI

By your argument, tool tips are bad because they also came up as a surprise (the 
user simply moved the mouse to a certain point and a tip popped up).

The other side of that coin is that undiscoverable features are completely 
useless in a UI.  What would make the user ever suspect that if he wants to see 
a list of possible values, he should double-click on the field.  When he 
single-clicks on the field is the time that he is about to enter information so 
that is the time that he would like to see previously-saved values if any.

> A single click to open the menu is unacceptable because it would obscure
> other elements in many fields.

Not if the list is hardly ever longer than one or two which I still contend that 
it is.  For example, how many last-names do you think the average user has?

> For example, if I wanted to change the `Summary' field of this bug report
> but clicked in the `URL' field by mistake, the `Summary' field would get
> covered with a menu of the various URLs I had entered for bugs in the past.

That's certainly not the way the form-manager feature is intended to be used.  
Neither "summary field" nor "url field" appear as recognizable schema to form 
manager (see the list of recognizable schema presented in 
tasks->privacy->form-manager->view-stored-data).  So when I user goes to submit 
a bugzilla form, he will never be asked if he wants to save those values.  He 
can save them manually (from the edit or context menu) but that would be a 
strange thing to do.  And if he hadn't done such a saving, there would be no 
values for URL and so no menu appears when he clicks on the URL field.

Keep in mind that this is not autocompletion where all values are saved 
automatically whenever you fill them into a field.  Here the user has to take 
some action each time he wants a value saved.  With autocompletion I would agree 
with you that you will quickly accumulate many values for each field.  With 
autofill (and it's need for an explicit action to do a save), that is not the 
case.

> I think Steve is trying to make a distinction between `autofill' and 
> `autocomplete' where such a distinction means nothing to the user.

Yes I am makins such a distinction.  Although the user might not understand the 
terms, he would certainly be aware of the differences in these two features.  
One is a feature requiring him to explicitly take an action when he 
wants to save a value and the other collects saved values behind his back.

> The menu should only show options that begin with the characters already
> entered in the field; when the field is empty, this is obviously equal to
> the total collection of options.

Again, this would be true of an autocompletion feature but not an autofill one.  
For autofill, the user has saved possibly one (and in rare cases two) values for 
a field.  When he first enters the field he would like to see any possible saved 
values from which to chose.  Once he starts typing he has decided that he 
doesn't want to use one of the saved values and so has no further need for the 
list.

> For example, what if I want to look up the same word in a number of
> different online dictionaries? Or if I want to look up the same title in a
> number of different online bookstores? Or if I want to do a Web search to
> find reviews of a book that I couldn't find reviewed in any online bookstore?
> Is this menu not going to help me, because the fields in each are considered
> to be in different schemata?

The answer to you last question is "yes", form-manager will not help you here.  
Let me explain why and give some history.

Form manager attempts to determine the schema for each field and its storage 
consists of the schema/value pair.  The question then comes up as to what to do 
is we can't determine the schema.  We certainly want this field to be 
pre-fillable the next time the user returns to this site.

My original idea was to save it as fieldname/value in this case and then reuse 
it whenever the user encountered that fieldname on any site.  But product 
marketing presented a convincing case against doing so.  A banking site might 
use "ss" as the field name for "social security number" and a shoestore site 
might use it for "shoe size".  Certainly you don't want to prefill the users 
social security number onto the shoestore's site.

So I changed the implementation as follows.  Instead of storing the information 
as fieldname/value, I store it as url:fieldname/value.  Now that value will be 
prefilled only on the original site for which it was captured, whereas schemas 
that I can recognized will be prefilled across sites.

So let's return to the example you sited.  Each of the fields you sited are not 
in the set of schema that we recognize.  So those values would not be shared 
across sites.

> And finally, ordering. Chronological ordering would perhaps be marginally
> better than alphabetical ordering

Once again the issue boils down to size.  If you have more than five items saved 
for a particular schema, then you are using form manager in a very 
unconventional way.  The original name for form-manager was "wallet" and the 
idea was that you carried certain personal information in your wallet (social 
security card, driver's license, credit card, etc) and you would like to avoid 
having to retype that same information on every website you visit.  So the 
"wallet" feature, upon request, would enter that information for you.  You have 
only one social security number.  You have only one driver's license number.  
You might have two or three credit card numbers so here's a case where you could 
get more than one saved value.  But in that case there is probably one number 
that you use most often so you would want to see the list sorted by 
most-recently used.

I mentioned above that I took great pains to keep the list sorted by MRU and one 
of the commentors above misinterpreted that as an excuse for not changing it:

      I appreciate your effort to allow chronological sorting, but that's not
      justification for doing it.  The ultimate goal here is maximum usability
      for the user, not less work for the developer, as harsh as that sounds.

On the contrary, I was not looking for "less work" when I chose to use the MRU 
algorithm -- rather I chose to use do the extra work because I felt (and still 
feel) that the most-recently used value is probably the when the user would want 
to use next.

I hope these comments help to clarify some of the issues.

Comment 21

[Alec Flett]

bugs are not the place to argue whether or not a bug should or should not be
fixed - take this up on a newsgroup and let's keep the traffic in this bug
relevant to HOW to fix this bug, such as if using C++ is the appropriate method
here.

Comment 22

[Karl Ove Hufthammer]

Note that this should also be possible using only keyboard and not mouse (or 
any other pointing device).

Comment 23

[Stephen P. Morse]

Trying to get this bug back on track.  I requested a super-review on this from 
alecf and his response was:

     "I don't understand why we're inventing a third type of popup in C++..
      why can't there be a XUL solution to this? I can't sr= this until we
      hear back from hyatt."

Dave, can you please comment on Alec's questions so we can make some progress on 
this one.  Is there anything that I should be doing to move this along?

Comment 24

[David Hyatt]

Patching the XUL popup listener is absolutely not allowed.  I will not approve
any patch that alters the popup listener in this way.

Comment 25

[David Hyatt]

As module owner of nsXULPopupListener, I will not allow a checkin that creates a
new kind of popup.  This is a hack.

Comment 26

[David Hyatt]

This bug should simply be tabled for 6.5 and be marked as dependent on XBL form
controls.  With XBL form controls, textfields could have a dropdown menu (like
Internet Explorer) built in to them.

Hacking the XUL popup listener will only work for Seamonkey, and it won't work
in embedding.  If we take the time to do this right (using XBL form controls and
thinking more about what UI should be presented), then I think we'll be much
better off.

Comment 27

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

Some comments on the patch, and the UI: 

- the positioning of the prefill menu is not skinable. Skins can change the font 
and the size of textfields, and so the code used to lower the position of the 
popup is likely to be incorrect in some cases. 
- the files are located in an inappropriate place in the source tree. All wallet 
code must be completely self contained inside extensions/wallet. 

As for UI, I have not applied the patch but I have some simple questions (I may 
apply the patch later today). - 
- the single click popup action, does this interfere with click to focus of the 
field, or click selection in the field (selecting text) or multiple click 
selection of words and the entire field? The UI that is posed should not obscure 
the textfield in anyway so as to prevent such editing operations.

The code issues raised by David Hyatt and myself are enough to make the patch in 
its current form fail r= and sr=. I will try the patch and experiment with the 
UI before issuing a judgement as UI module owner. 

Comment 28

[Mike Pinkerton (not reading bugmail)]

as the other module owner for popups, I totally agree with hyatt. Nothing in 
this patch enhances the toolkit for applications, but simply adds a browser-
specific feature and should be done outside the realm of the toolkit.

adding myself to the cc list.

Comment 29

[Loco]

I stopped watching soaps.  Need my intake.

Comment 30

[Stephen P. Morse]

Per vishy's request, here is my recommendation for this bug regarding nsbeta1.

Currently there is no means of discovery for the form manager unless either this 
feature is implemented or the form-manager toolbar (bug 23095) is restored 
(commenting-out removed).  That is why I nominated this for nsbeta1 originally.  
However I don't realistically see this feature being implemented in the near 
future.  So I'm at a loss as to whether to which recommendation to make here 
(nsbeta1+ or nsbeta1-).

Comment 31

[Viswanath Ramachandran]

since we do not have a proper solution here in the timeframe for mozilla0.9.1, 
we will nsbeta1- this bug. 

Comment 32

[Ian Pottinger]

adding self to cc list

Comment 33

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This might be related to bug 180924.

Reassigning to new module owner dveditz.

Comment 34

[Craig]

As Mozilla stores tens of irrelevant data items along with the relevant ones for
a field, it would be extremely useful if there was a drop-down as suggested here.

Comment 35

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 36

[Justin Dolske [:Dolske]]

This 8 year old flamewar is no longer relevant. The old code has been replaced by satchel and password manager, and thing issues no longer apply. Lest any daring young necromancer feel strongly about some random point here, please file new bugs.