Open Bug 453255 Opened 16 years ago Updated 2 years ago

Use clickSelectsAll in search fields

Categories

(Firefox :: General, enhancement)

enhancement

Tracking

()

People

(Reporter: Natch, Unassigned)

Details

(Whiteboard: [needs new patch])

Attachments

(2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Spin-off of bug 317419 for Seamonkey, this one's for Firefox.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
This is all for firefox, as requested I put it in a separate bug, the Seamonkey stuff I'll put in the other bug.
Attachment #336441 - Flags: review?(gavin.sharp)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #336441 - Attachment is obsolete: true
Attachment #336441 - Flags: review?(gavin.sharp)
Comment on attachment 336441 [details] [diff] [review]
Firefox complete patch (toolkit/browser)

gotta update, new patch coming
Attached patch Updated to HEAD (obsolete) — Splinter Review
Changes to Browser and Toolkit.
Attachment #337547 - Flags: review?(gavin.sharp)
gavin: is firefox interested in taking this at all?
Assignee: nobody → highmind63
Comment on attachment 337547 [details] [diff] [review]
Updated to HEAD

-                   oncommand="doFind();"/>
+                   oncommand="doFind(); clickSelectsAll="true"/>

Not good! :( . I'll redo this if this interests anyone. :)
Attachment #337547 - Attachment is obsolete: true
Attachment #337547 - Flags: review?(gavin.sharp)
Sorry I didn't comment earlier, thought I had... I'm not sure I understand the rationale behind adding clickSelectsAll to these. clickSelectsAll makes it easier if you're frequently entering new text as opposed to editing existing text (e.g. URL bar and search bar), and I'm not sure if that's the case for each of the textboxes being changed here. I guess I don't feel strongly either way - perhaps someone on the UX team does? :)
Keywords: uiwanted
-> default owner
Assignee: highmind63 → nobody
(In reply to comment #6)
> each of the textboxes being changed here. I guess I don't feel strongly either
> way - perhaps someone on the UX team does? :)

Alex, what is your position here?
Component: Search → General
QA Contact: search → general
Would be nice to get some input from UX here, I believe this is wontfix...
Whiteboard: [wontfix?]
>I'm not sure if that's the case for each of the textboxes being changed here.

What are the other search text boxes in play here, thinks like find bar, about:config, and the applications prefpane?  For those three the last two should be clicksSelectAll, but not the find bar (where users are more likely to tweak the existing text).  I don't care about the default behavior, but we should ideally give some thought to each instance of the search field to make sure we are making the right call on the probability of new text versus tweaking.
Thanks Alex! To sum-up, I imagine any patch would have to go through ui-review to ensure the correct attributes are applied to the proper fields.
Keywords: uiwanted
Whiteboard: [wontfix?] → [good first bug] [needs new patch]
perhaps generally speaking search fields tend to get new information, so we should default to clickSelectsAll?  Kind of hard to say for sure in the abstract.  Either way we should give each field some thought.
Version: unspecified → Trunk
Given the age of this bug, would it make sense to mark this wontfix, and address any encountered future cases as specific / targeted issues?
Whiteboard: [good first bug] [needs new patch] → [needs new patch]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: