Some users expect to be able to click once in Navigator's location field to select the whole contents of the field. Other users find this behavior in other browsers to be extremely annoying. I suggest that, as a way of making both parties happy, clicking once on the proxy icon area at the left side of the location bar should select the whole contents of the field. This would allow users to quickly select the field's contents, without annoying those who want to select or edit part of the data. It would fit intuitively with the ability to copy the location somewhere by dragging the location field, as other draggable items are normally selected before they are dragged. Notes: * This should work whether or not the proxy icon is actually present (bug 37462). * If this is implemented, the cursor for hovering over the proxy icon should be the arrow pointer rather than the hand pointer (contrary to bug 18836), as the proxy icon would now be useful for selection as well as dragging. (Compare with icons in a file manager, which have the arrow pointer instead of the hand pointer because they can be selected as well as dragged).
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Surprisingly, I agree with the reporter. --> URL Bar
Assignee: mpt → hewitt
Component: User Interface Design → URL Bar
QA Contact: zach → claudius
+ <deck id="page-proxy-deck" + onclick="gURLBar.select();"> couldn't this be on one line?
Stephen: I think you should not remove the grab feedback. With your patch, no indication is provided to inform the user that he/she can drag the proxy icon. Having the grab cursor when one wants to select the url bar is not a problem, since there is still the idea of grabbing the selection for future use (copy, delete)
Created attachment 93315 [details] [diff] [review] patch v1.1 Pierre, it doesn't look like we use the grab cursor anywhere else to inform users that an item can be dragged & dropped, so why should we show it for the urlbar? If the proxy icon is present, there is also a tooltip that explains that the icon can be used to create a link by d&d.
Attachment #93239 - Attachment is obsolete: true
Stephen: - as an individual, of course, I don't care about the removal of the grab cursor since I already know I can drag the proxy. Thought: - when thinking to new users: for lists, trees or group of items, the user already has the experience (throught the OS) that he/she can re-order or extract an item: the grab cursor is unnecessary and would be distracting. On the contrary, the url proxy is isolated and needs imho an extra-feedback. The reason why the grab cursor is used in a single place in mozilla may (should) be that the location field is the only isolated place in Mozilla where DND is possible. (if there are other isolated draggable item, bugs should be filed). - users that know this feature, since there is no feedback on :hover and because the proxy icon size is small (16x16), have to target accurately the proxy icon and thus needs an immediate feedback to tell if dragging is possible at the current position of the mouse. Maybe a bug 'replace the grab cursor feedback with a :hover effect' should be filed but it would definitely be a bad idea to let for an unknown period of time the proxy icon without feedback. Let's restrict this bug to its subject: enabling the user to select the location field, unless you can quickly fix the feedback problem. Mpt: what did you have in mind when you committed this laconic me-too comment: 'stephen's right'. Does it imply that you know for this particular point what is right and what isn't for Mozilla? You have many good ideas about Mozilla but please, don't be arrogant when facing criticisms concerning your proposals.
This almost works now that bug 158364 is fixed, but it doesn't work if the location bar has focus before you click the icon.
The fix for this is included in attachment 94596 [details] [diff] [review], which is a patch for bug 111337. Now if only it were reviewed and checked in.
Fix to bug 111337 checked in, which I believe also fixes this.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.