Closed Bug 233977 Opened 20 years ago Closed 19 years ago
Single-click selects entire address bar rather than activates cursor
User-Agent: Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040125 Camino/0.7+ In Cocoa browsers like Camino and Safari, clicking in the address bar places the cursor at that point, so the address can be edited. Cmd-L is for selecting the entire field so that one can go to a new location without having to reach for the mouse (going to a new location from the address bar requires keyboard input anyway). In Firefox, clicking on the address bar selects the whole address bar so getting to the cursor for editing, say adding a period, requires two single-clicks. A double-click, by the way, selects a single word. Selecting the entire address bar should not be the default action for single-clicking the address bar, since keyboard input is always desired next and selecting the address bar can be achieved from the keyboard with Cmd-L. Editing the address, on the other hand, is served well by mouse input so the cursor can (or should) be placed at a particular, desired point as simply as possible. Also, Cocoa text fields allow for emacs bindings (built-in for Cocoa applications in Mac OS X). Ctrl-K to "kill" the rest of the line is extremely handy for navigating to an upper-level of the website from the address bar. Reproducible: Always Steps to Reproduce: 1. Click the address (location) bar. 2. 3. Actual Results: All text in address is selected Expected Results: Cursor should be active at point clicked
marking enhancement... don't think that this is quite a bug
Severity: normal → enhancement
out of curiosity, what does about:buildconfig say?
dup of Bug 229473?
Not a dup of bug 229473. This bug is aggrivating for Mac users, as we expect all text fields in all apps to behave consitantly, yet the location bar in Firefox behaves in a totally unexpected way. I can't count how many times I have clicked on the end of a URL to add a subdirectory only to have the original URL disappear as soon as I start typing. Correct me if I'm wrong, but I believe this behavior has already been removed from the Linux version. If so, it should also be removed from the Mac version. Changing severity from enhancement to minor as this bug makes me want to switch back to using Safari when I encounter it. Plus, it's probably a violation of Apple's Human Interface Guidelines.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The behavior of Camino's address bar is what Mac users would expect. Would it be possible to graft Camino's address bar into Mac Firebird? If not, we should at least stop it from selecting the entire URL on a single click.
(In reply to comment #5) > The behavior of Camino's address bar is what Mac users would expect. Would it be > possible to graft Camino's address bar into Mac Firebird? If not, we should at > least stop it from selecting the entire URL on a single click. That is most definitely not possible, since Camino is Cocoa and Firefox is XUL. Howerver, I agree that the behavior should be changed to match the OS X standard.
This is a patch against Firefox.app/Contents/MacOS/res/builtin/platformHTMLBindings.xml When applied, it makes emacs/Cocoa bindings available in the address bar and other input fields, without breaking any existing bindings that I'm aware of.
The Mozilla equivalent bug for this is bug 233977. It's apparently a preference, and I just verified this preference is present in Firefox. The default needs to be changed to match the Aqua HIG though. Bug 233977 was WONTFIXed however. Someone said "HIG be damned" or something to that effect. I just reopened it.
(In reply to comment #7) > Created an attachment (id=158886) > Makes emacs/Cocoa-style key bindings available on Mac OS This attachment belongs on bug 229473, not here.
Summary: Single-click selects entire address bar rather than activates cursor - Cocoa-style address (location) text fields, including emacs bindings → Single-click selects entire address bar rather than activates cursor
See also Bug 134649 (browser.urlbar.clickSelectsAll should default to false on Macintosh).
*** Bug 264934 has been marked as a duplicate of this bug. ***
*** Bug 275242 has been marked as a duplicate of this bug. ***
*** Bug 264934 has been marked as a duplicate of this bug. ***
All we have to do to fix this bug is add the following default preference: pref("browser.urlbar.clickSelectsAll", false); Can someone write up a patch to do that?
Below is the patch for Mozilla (bug 134649). Would the patch for Firefox be any different? Index: modules/libpref/src/init/all.js =================================================================== RCS file: /cvsroot/mozilla/modules/libpref/src/init/all.js,v retrieving revision 3.551 diff -u -r3.551 all.js --- modules/libpref/src/init/all.js 28 Oct 2004 18:54:22 -0000 3.551 +++ modules/libpref/src/init/all.js 19 Nov 2004 20:25:04 -0000 @@ -1213,6 +1213,7 @@ pref("font.size.variable.zh-HK", 15); pref("font.size.fixed.zh-HK", 16); +pref("browser.urlbar.clickSelectsAll", false); pref("browser.urlbar.clickAtEndSelects", false); // Tab focus model bit field:
Seems like that patch would work. I just set the pref: browser.urlbar.clickSelectsAll = false in about:config and it works for me in Firefox 1.0. Yay!
*** This bug has been marked as a duplicate of 134649 ***
Status: NEW → RESOLVED
Closed: 19 years ago
No longer depends on: 134649
Resolution: --- → DUPLICATE
un-duping per bug 134649 comment 40.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
apparently, the pref needs to be set in firefox.js rather than all.js in order to fix this for Firefox.
See also: bug 218315 comment 21. Can someone pick appropriate reviewers for this?
double-read bug 134649 comment 39.
> This bug is aggrivating for Mac users, as we expect all text fields in all > apps to behave consitantly Depends how recently you became a Mac user. Mozilla browsers have been doing click-selects-all on the Mac ever since Netscape Navigator 3.0. For the original 2000~2001 debate (with Ben and Blake in starring roles), see bug 37587. Whichever way you go, the behavior will aggravate many people (personally, Safari's click behavior is the thing about Safari that wastes more of my time than anything else). However, click-selects-all could be made less *surprising* by adding some visual distinction, e.g. bug 78082.
*** Bug 287121 has been marked as a duplicate of this bug. ***
With the Windows version, a single click on the address bar highlights the entire address. The Linux version however, a single click will place the cursor in that location. Which way is it supposed to operate?
It's supposed to operate as follows (according to OS conventions): Windows: single-click selects entire address Linux and Macintosh: single-click places cursor The proper behavior in Linux was implemented long ago, but the fix for Mac has been stonewalled.
>For the original 2000~2001 debate (with Ben and Blake in starring roles), see bug 37587. That debate concerns the behavior across all platforms (and thus mainly concerns the Windows version). This bug is specifically about the behavior on the Mac platform. Currently, the Linux version conforms to standard unix behavior, but the Mac version is forced to behave like a Windows app. This is a straightforward case of OS convention compliance. The patch to fix this bug has been sitting here for 4 months. Any chance someone could review it?
Comment on attachment 173360 [details] [diff] [review] Remove #ifndef XP_MACOSX r=me on the change, but for sanity's sake change this bit to: #ifdef XP_UNIX pref("browser.urlbar.clickSelectsAll", false); #else pref("browser.urlbar.clickSelectsAll", true); #endif This doesn't change the end result, but the firefox.js after processing should be a bit cleaner.
Attachment #173360 - Flags: review?(mconnor) → review+
for the branch we are only taking security fixes or regressions from security fixes.
Flags: blocking-aviary1.0.6? → blocking-aviary1.0.6-
Has r=mconnor, asking for approval.
(In reply to comment #29) > Created an attachment (id=189722)  > Updated > > Has r=mconnor, asking for approval. I really doubt we want take this change. This is going to be a real usability issue (especially, in a post-1.0 release). CCing Ben, mconnor and mpt.
This seems like a no-brainer. We've heard time and time again that one of the biggest critiques of Firefox on OS X is that it doesn't behave like an OS X application. Whether you love or hate the OS X behaviour is a different debate, IMO. We need to respect the fact that our mac users bought macs, and that most of their applications respond to clicks in text boxes by placing an insertion cursor at that point. We should do the same.
Attachment #189722 - Flags: approval1.8b4? → approval1.8b4+
Checking in browser/app/profile/firefox.js; /cvsroot/mozilla/browser/app/profile/firefox.js,v <-- firefox.js new revision: 1.61; previous revision: 1.60 done
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox1.1
Version: unspecified → Trunk
> /cvsroot/mozilla/browser/app/profile/firefox.js,v <-- firefox.js > new revision: 1.61; previous revision: 1.60 Mac mouse users now need to *triple*-click their urlbar in order to open a new location. Can we get some sort of usability test here?
or click+drag, or Ctrl-L. We've kicked this football around forever, some like it, some don't, we're going with the OS behaviour, end of story.
>Mac mouse users now need to *triple*-click their urlbar... Yes, this is now identical to how every other Mac program functions - single click to place cursor, double-click to select word, triple-click to select entire line. This should be the normal and expected behavior for Mac users. Thanks for fixing this!
(In reply to comment #34) > or click+drag, or Ctrl-L. We've kicked this football around forever, some like > it, some don't, we're going with the OS behaviour, end of story. In Camino and Safari, clicking the favicon (as opposed to the URL) gets you the entire URL selected with one click. Dunno if that is something it's possible to implement in Firefox for people who need one-*click* selection of the entire URL.
*** Bug 307369 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.