Search fields in the UI don't follow standard OS text selection behaviour

RESOLVED FIXED

Status

defect
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: torben, Assigned: hwaara)

Tracking

({fixed1.8.1})

Details

Attachments

(1 attachment)

602 bytes, patch
stuart.morgan+bugzilla
: review+
mikepinkerton
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

13 years ago
The standard behaviour for text fields on OS X is:
single click - place cursor
double click - select word
triple click - select all

Clicking once in the Google search field on the main toolbar, however, will select everything. Camino's behaviour in the location field is correct (and suggestions to change this has rightfully been wontfix'ed) Safari behaves correctly for both fields.
This occurs on the trunk too; changing version to "unspecified".
Version: 1.8 Branch → unspecified
(Assignee)

Comment 3

13 years ago
(In reply to comment #2)
> Stuart fingered this as the culprit: 
> http://lxr.mozilla.org/mozilla/source/camino/src/browser/BrowserWindowController.mm#1682

No, that function is not called upon clicking the search textfield. 

The culprit is that NSTextField's becomeFirstResponder: for some reason calls selectText: (which we override).
(Assignee)

Comment 4

13 years ago
Camino 1.1 is where we switch to Mac OS 10.3, right?

If that's the case, we can use cocoa's NSSearchField instead of our own (re-)implementation of this!
(In reply to comment #4)
> Camino 1.1 is where we switch to Mac OS 10.3, right?
> 
> If that's the case, we can use cocoa's NSSearchField instead of our own
> (re-)implementation of this!

Yeah; isn't that bug on the 10.2-dropping meta already?  Oh, smfr did some fixes in bug 235848 to make the ring passable, so that bug got "fixed".

We have several of these search fields (the search sheet, the 2 in cookie prefs, and the one in the Bookmarks Manager), and afaict, they all have this selection problem.
Blocks: 311840
Summary: Google search field doesn't follow standard OS text selection behaviour → Search fields in the UI don't follow standard OS text selection behaviour

Comment 6

13 years ago
(In reply to comment #3)
> (In reply to comment #2)
> > Stuart fingered this as the culprit: 
> > http://lxr.mozilla.org/mozilla/source/camino/src/browser/BrowserWindowController.mm#1682
> 
> No, that function is not called upon clicking the search textfield. 

That's why I shouldn't come up with theories by glancing at the source late an night ;)

> The culprit is that NSTextField's becomeFirstResponder: for some reason calls
> selectText: (which we override).

That's not exactly the culprit; standard NSTextFields do not behave the way Camino's search does, despite the fact that becomeFirstResponder: calls selectText:.

The real culprit (and this isn't just a random guess this time) is that the mouseDown: override doesn't give super a chance to do the right thing; it's a dead end even if the click wasn't on the cancel button or the drop-down. This could be fixed just by adding a call to super in the unhandled cases, and I can't see any downsides to doing so.
(Assignee)

Comment 7

13 years ago
Yeah, this works perfectly.
Attachment #214556 - Flags: review?(stuart.morgan)
(Assignee)

Updated

13 years ago
No longer blocks: 311840
-> Håkan, since he's working on it.
Assignee: mikepinkerton → hwaara
(Assignee)

Comment 9

13 years ago
Comment on attachment 214556 [details] [diff] [review]
Per Stuart's suggestion

This is trivial, feel free to r/sr whoever wants to.
(Assignee)

Comment 10

13 years ago
Filed bug 330666 for going over to NSSearchField
Comment on attachment 214556 [details] [diff] [review]
Per Stuart's suggestion

sr=pink
Attachment #214556 - Flags: superreview+
(Assignee)

Comment 12

13 years ago
Fixed on trunk and branch.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED

Updated

13 years ago
Attachment #214556 - Flags: review?(stuart.morgan) → review+
You need to log in before you can comment on or make changes to this bug.