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)

x86
Windows NT
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: morse, Unassigned)

References

Details

Attachments

(3 files)

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)
Status: NEW → ASSIGNED
Whiteboard: [w]
Blocks: 48860
Just interested in following progress :)
Netscape Nav triage team: this is a Netscape beta stopper.
Keywords: nsbeta1
Priority: -- → P2
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
Attached patch Patches for changed files (deleted) — — Splinter Review
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.
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
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.
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
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.
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
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
Keywords: nsbeta1
This bug was nominated as nsbeta1 by the triage team. See knous' comment on 12-21.
Keywords: nsbeta1
I was renominating it the only way I know how to. I think they made a mistake, since this is a new feature...
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.
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.
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.)
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.
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.
Whiteboard: [w]
Note that this should also be possible using only keyboard and not mouse (or any other pointing device).
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?
Patching the XUL popup listener is absolutely not allowed. I will not approve any patch that alters the popup listener in this way.
As module owner of nsXULPopupListener, I will not allow a checkin that creates a new kind of popup. This is a hack.
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.
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.
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.
Target Milestone: --- → mozilla0.9
I stopped watching soaps. Need my intake.
Target Milestone: mozilla0.9 → mozilla1.0
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-).
since we do not have a proper solution here in the timeframe for mozilla0.9.1, we will nsbeta1- this bug.
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.1
adding self to cc list
Priority: P2 → P3
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
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 → ---
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.
Assignee: dveditz → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: tpreston → form-manager
Product: Core → Toolkit
QA Contact: form-manager → form.manager
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.

Attachment

General

Created:
Updated:
Size: