Closed
Bug 63320
Opened 24 years ago
Closed 16 years ago
Double clicking on text field to bring up a list of possible entries
Categories
(Toolkit :: Form Manager, defect, P3)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: morse, Unassigned)
References
Details
Attachments
(3 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details |
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)
Reporter | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [w]
Comment 1•24 years ago
|
||
Just interested in following progress :)
Comment 2•24 years ago
|
||
Netscape Nav triage team: this is a Netscape beta stopper.
Keywords: nsbeta1
Priority: -- → P2
Reporter | ||
Comment 3•24 years ago
|
||
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
Reporter | ||
Comment 4•24 years ago
|
||
Reporter | ||
Comment 5•24 years ago
|
||
Reporter | ||
Comment 6•24 years ago
|
||
Comment 7•24 years ago
|
||
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.
Reporter | ||
Comment 8•24 years ago
|
||
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.
The patches look ok to me.
The design seems simple, straightforward and intuitive.
r: pnunn
Comment 10•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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
Reporter | ||
Comment 15•24 years ago
|
||
This bug was nominated as nsbeta1 by the triage team. See knous' comment on
12-21.
Keywords: nsbeta1
Comment 16•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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.)
Reporter | ||
Comment 20•24 years ago
|
||
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•24 years ago
|
||
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.
Reporter | ||
Updated•24 years ago
|
Whiteboard: [w]
Comment 22•24 years ago
|
||
Note that this should also be possible using only keyboard and not mouse (or
any other pointing device).
Reporter | ||
Comment 23•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
As module owner of nsXULPopupListener, I will not allow a checkin that creates a
new kind of popup. This is a hack.
Comment 26•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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.
Reporter | ||
Updated•24 years ago
|
Target Milestone: --- → mozilla0.9
Comment 29•24 years ago
|
||
I stopped watching soaps. Need my intake.
Reporter | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9 → mozilla1.0
Reporter | ||
Comment 30•24 years ago
|
||
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•24 years ago
|
||
since we do not have a proper solution here in the timeframe for mozilla0.9.1,
we will nsbeta1- this bug.
Reporter | ||
Updated•23 years ago
|
Target Milestone: mozilla1.0 → mozilla1.1
Comment 32•23 years ago
|
||
adding self to cc list
Reporter | ||
Updated•22 years ago
|
Priority: P2 → P3
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
Reporter | ||
Updated•22 years ago
|
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
This might be related to bug 180924.
Reassigning to new module owner dveditz.
Assignee: morse → dveditz
Status: ASSIGNED → NEW
Target Milestone: mozilla1.3alpha → ---
Comment 34•20 years ago
|
||
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.
Updated•20 years ago
|
Assignee: dveditz → nobody
Comment 36•16 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•