Closed Bug 409810 Opened 17 years ago Closed 16 years ago

Clicking location bar selects the whole URL rather than setting insertion point

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: cmhofman, Unassigned)

References

Details

(Whiteboard: [parity-safari] [See comment #12 for fix]) 

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2007122504 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2007122504 Minefield/3.0b3pre

When I select the address field using the mouse, the whole text in the address bar is selected, rather than just inserting the cursor in the text where I entered the mouse.

Reproducible: Always

Steps to Reproduce:
1. Select the address bar using mouse down
2.
3.
Actual Results:  
The whole text in the address bar is selected

Expected Results:  
The cursor should be inserted at the place where I put the mouse and no text should be selected. Text should be selected only on double or triple click.
This change was intentional.  See bug 406706.

Do you dislike the new behavior, or did you only file this bug report because you didn't know it was intentional?  If you dislike it, why?
I didn't know it was intentional, and I find it extremely annoying. It makes it pretty hard to change something in the address.
Depends on what kind of change you're trying to make.  If you want to delete or replace part of the URL, you can select it using a drag motion.  The new (for Mac) behavior only affects clicks where the cursor doesn't move between mousedown and mouseup.
Summary: Selecting location bar selects whole text rather than setting insertion point → Clicking location bar selects the whole URL rather than setting insertion point
Blocks: 406706
(In reply to comment #1)
> This change was intentional.  See bug 406706.
> 
> Do you dislike the new behavior, or did you only file this bug report because
> you didn't know it was intentional?  If you dislike it, why?
> 

Personally, I hate this change.  It is annoying to get used to considering that
every other browser on OS X does not select the location bar text on a single
click.  It ruins consistency with every other text field a user encounters in
OS X.  This could be a major issue for me upgrading to Firefox 3 unless there
is a preference that can be changed either in the browser preferences or in
about:config.
From http://daringfireball.net/2008/04/firefox_3_safari_3 :

The new Firefox 3 location field, the so-called “AwesomeBar”, is too clever. When I click the mouse in the middle of a URL, I just want to place the insertion point. I don’t want to select the entire URL. If I wanted to select the entire URL, I’d double-click. Click to place, double-click to select — /just like any other text field/.
i have seen users complaining about not being able to select whole url easily as well, since favicon now doesn't do this anymore.

I, for one, like the change, and I think mozilla should do a survey before revert it back. 
I just switched to the new Firefox 3.0 series and hit this issue.  While I like most things about Firefox 3.0, this is terrible!  I use Command-l to select the entire URL in the location bar.  If I click in it I want to position the cursor.  I've always hated this behavior on windows (using IE, not sure what Firefox does on windows).

Please at least add on option to turn this  behavior off or better yet revert it.
CCing faaborg@mozilla.com.

Can people who commented here (or other people who care) please vote for this bug so that we have an easy way to know how many people are complaining?

As there were little (if any) requests for the change, whereas the modified behavior seems to be bothering quite a few people, I think we should consider reverting.
>As there were little (if any) requests for the change, whereas the modified
>behavior seems to be bothering quite a few people, I think we should consider
>reverting.

That is based on the premise that people with bugzilla accounts are a representative sample of our user base.  I believe people who use bugzilla are very likely to modify the URL because they are most likely developers and therefor accustomed to modifying arcane strings.  I also believe that people who do not use bugzilla are highly unlikely to modify an existing URL.  Since the later user group is several orders of magnitude larger, even a few hundred votes by people in the former user group is not likely to convince me that we are actually making a mistake for our users.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
I see this is marked "resolved wontfix" (is that new?) but does it really need to all or nothing.  How about leaving the present behavior but adding a hidden preference to revert the behavior to Firefox 2 style?
Flipping the default value of a pref was how this change was implemented, the pref is browser.urlbar.clickSelectsAll
Whiteboard: [See comment #12 for fix]
Reopening for parity with Safari.  I don't know why Mike Beltzner said "Definitely for OS X" in bug 406706 comment 2.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Whiteboard: [See comment #12 for fix] → [parity-safari] [See comment #12 for fix]
>Reopening for parity with Safari.  I don't know why Mike Beltzner said
>"Definitely for OS X" in bug 406706 comment 2.

We thought that at one point Safari had what we strongly believe is the correct behavior.  Full discussion (and about:config patch to reverse the behavior) is in bug 406706
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → DUPLICATE
Alex, a workaround is not a solution.  I know that _I_ can fix this, however, customers (sure, the product is free, but marketshare still matters) would not be so happy having to delve into what is seen as a place where "warranties are voided" to fix something that's broken for poor reasons to begin with.

Are you saying that Safari used to select the whole URL bar, instead of setting the insertion point? If so, I will be happy to file a bug on the webkit bugzilla and check to see if this is true, and what their official stance is.  I do not like having to do that, as I have done in the past.  See https://bugs.webkit.org/show_bug.cgi?id=18295 for me proving parity with safari to prevent bug 414057 from being resolved, and https://bugs.webkit.org/show_bug.cgi?id=19648 for me proving that bug 349357 comment 5 was incorrect and that tab selecting select menus is a feature, not a bug in Safari.
I meant to dupe this to bug 406706 as a duplicate of discussion, not a duplicate of intention.  But since they are indeed opposites, I'm switching this back to wontfix.

>Are you saying that Safari used to select the whole URL bar, instead of setting
>the insertion point?

I could have sworn that was the case, but it's entirely possible that I'm wrong.  But the important issue isn't who did what, but rather which approach is better.
Resolution: DUPLICATE → WONTFIX
Coming in from a bug that was marked as a dupe of this.

This new behavior is horrible, is very disruptive, and is confusing my users and keeping some of them from adopting Firefox willingly.

Firefox is on it's own in this one. Mac users expect a single-click in a text box to insert the cursor, not (seemingly) randomly highlight the whole field. For the very non-computer-savvy users I support, this has led them to conclude things like 1) Firefox is broken, 2) their mouse is broken, 3) that it's not a "normal" text box and therefore they're not "allowed" to type there. Obviously, once I figure out what they're complaining about, I can just change the pref in about:config. However, some of them already are too **** off at Firefox to give it a fair chance after that. Also, what about all the other confused users who go back to Safari because no one showed them how to fix the brokenness?

Seriously, guys, you're alienating new users which is not good for market share.
This really should be fixed! In all Mac apps, we click once to place cursor, twice to select word and thrice to select paragraph. Only in Firefox to I have to click thrice to place cursor, twice to select word and once to select the whole URL. The pref at browser.urlbar.clickSelectsAll is ok but it should default to false.
Since someone was dumb enough to mark this "WONTFIX", is there anyone even seeing this comments that has the authority to realize how badly the dev team screwed up on this one?
Verifying WONTFIX per comment 21.
Status: RESOLVED → VERIFIED
Thank you, I appreciate that.


Also, I wrote comment 21 less tactfully than I should have. Please accept my apologies.
Wait, I mistook what Thomas K was doing.

Will the development team justify their reasoning for deliberately breaking the OS X user interface?
The change was made based on the reasoning in bug 406706. You can flip the pref from comment 12 using about:config if you want to change the behavior in your copy of Firefox. We're unlikely to make yet another change in the default behavior, especially since feedback has been mostly positive or neutral in general, from what I can tell.
Regarding Comment #25,
Feedback has been resoundingly negative from the non-dev-team community. I'm CC'd on at least 3 instances of this bug, all of which contain a number of people complaining about it.

I have also read, and do understand, the argument being made in bug 406706. However, I think the reasoning in that bug is *deeply* flawed when it comes to the case of the _mainstream_ user. The mainstream user won't know, or care, that the URL bar is supposed to be "special" (whatever that means). All the basic user is going to know is that, for no reason he or she can fathom, the mouse button suddenly does a different thing in Firefox than it does anywhere else on the entire computer (including the URL bar in other browsers).

I think it makes sense to give the user control over the behavior of the bar. However, I think that the default should be the behavior that is going to provide the least surprise and dismay (Principle of Least Astonishment) to the least common denominator user.

In other words, I'm perfectly capable of adjusting the prefs to make Firefox work the way I want it to. My grandmother isn't. Firefox's defaults need to confuse her the minimum possible.
(In reply to comment #26)
> Regarding Comment #25,
> Feedback has been resoundingly negative from the non-dev-team community. I'm
> CC'd on at least 3 instances of this bug, all of which contain a number of
> people complaining about it.

"a number" of people (10? 100?) complaining about it on Bugzilla don't represent a statistically significant portion of the Firefox user base. That isn't to say that their input is worthless, but taking into account only the input of people who 1) care strongly enough about the change and 2) can find Bugzilla tends to lead to poor decision making.

The argument in bug 406706 doesn't rely on people knowing that the URL bar is "special", it relies on the assumption that the most common use case for a URL bar is typing in an entirely new URL. I understand your argument about consistency, but I think it's pretty unlikely that your grandmother is tweaking URL components manually when she's surfing the web, so utility over consistency seems like a fairly reasonable choice to make.
You don't think hunt-and-peck typists ever type ".xom" rather than ".com" and have to fix just one letter? Since they don't understand what's going on with the URL bar, you've just doomed them to retyping the entire domain.

Honestly, I support enough end-users (I donate tech support time to a couple of small organizations of about 15 people each) that this behavior really does confuse them. They navigate the web in a much more limited fashion than you or I do. They click on links from other applications (pretty much email or their IM client). They type domain names into the URL bar (and need to fix their typos), they type in google.com and then search for the name of the place they want to go. I can count on one hand the number of times I've watched a normal user try to cut and paste in the URL bar.
I don't want to get into an argument of anecdotes, but the slow typists I know favor hitting backspace repeatedly over any kind of advanced text selection, and I never implied they used copy/paste, so I'm not sure why you brought that up.

I'm going to stop commenting now because the poor people on this bug's CC list have been spammed enough, and I don't think we're going to end up agreeing. Feel free to email me directly if you want to pursue the issue further.
Thanks Gavin, I'll defend the design decision when this comes up again in a week or so :)  In all seriousness I'm really looking forward to having TestPilot up and running so that we will have enough data to conclusively prove that one approach is more efficient than the other.  Otherwise we are going to remain stuck in the not particularly quantitative land of anecdotes about various computer users we know.
You don't need to do any test studies or focus groups. All Macintosh programs have behaved one way for 25 years. Firefox behaves totally differently. Any assertion that this is more intuitive or not a problem for Mac users is pure malarkey.
I'm not asserting that it is more intuitive, I'm asserting that once a user becomes accustomed to the behavior, they see a significant time savings nearly every single time they interact with the location bar.  Designing for the first run interaction is important, but in some cases designing for the next 10,000 ends up being more important.
(In reply to comment #32)
> I'm not asserting that it is more intuitive, I'm asserting that once a user
> becomes accustomed to the behavior, they see a significant time savings nearly
> every single time they interact with the location bar.  Designing for the first
> run interaction is important, but in some cases designing for the next 10,000
> ends up being more important.

Effectively, you're asserting that you have the authority to force the user to conform to your view of how things should be. If you were the OS designer, you might be onto something.

However, since you're designing only the browser, you're saying that users have to relearn what they already think they know just to work with your program. The behavior will never become customary to the user because the OS-correct behavior is constantly being re-enforced in every other program they use. Additionally, the OS-correct behavior is constantly being re-enforced in Firefox itself in every single UI element other than the address bar.
Ok how about this: try entering a search into spotlight, give the desktop the focus, and then give the spotlight control the focus again.

If I had been at Apple doing the UI of spotlight, I would have made that decision as well.

The finder's search field is a little strange, it flashes a select all and then sets the cursor point (like they couldn't decide and later changed the behavior at the wrong point in the code).

Anyway, I really am all for OS consistency, but this is kind of a special case since selecting everything is so much more advantageous (initial learning curve aside).
(In reply to comment #34)
> Ok how about this: try entering a search into spotlight, give the desktop the
> focus, and then give the spotlight control the focus again.
I did. The text is highlighted when you come back to it. HOWEVER, clicking once in the search field results in the insertion of the cursor with *nothing* highlighted, exactly like clicking in every other text entry box.

> Anyway, I really am all for OS consistency, but this is kind of a special case
> since selecting everything is so much more advantageous (initial learning curve aside).

If you want to put the cursor in the address bar with the entire contents highlighted, there's already a way to do that: Cmd-L. There's no reason to break the functionality of a mouse click to provide another way to do something that's already possible.
You need to log in before you can comment on or make changes to this bug.