Closed Bug 134649 Opened 22 years ago Closed 15 years ago

browser.urlbar.clickSelectsAll should default to false on Macintosh

Categories

(Firefox :: Address Bar, defect)

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

Tracking

()

Status:
RESOLVED DUPLICATE of bug 409810

People

(Reporter: bill+mozilla-bugzilla, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: polish, Whiteboard: fix-in-hand, needs usability testing (see comment 39))

Attachments

(1 file, 1 obsolete file)

patch (set browser.urlbar.clickSelectsAll to false on Mac)
579 bytes, patch
Brade
: review+
Details | Diff | Splinter Review 
Not Mac-like behavior.

This is a text field, a single click should give you an insertion point, a
double click should select the entire word (an entire URL should be covered, no
spaces) and a triple-click should select the entire line (e.g. space-separated
search terms).

This makes editing a URL very frustrating, especially if you're doing it over
and over, e.g. looking at all the images in a directory by changing the image
number.  You have to click, wait, click to get the behavior mac users expect
from just a click.
isn't there a hidden preference we can change for this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
qa --> claudius@netscape.com
QA Contact: paw → claudius
Dup of bug 116441, and thence bug 62495.

*** This bug has been marked as a duplicate of 116441 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
I'm reopening this because I've done some research and I think this is a 
Mac-specific bug now and this behavior arose from non-mac people not doing their
 homework.

Setting clickSelectsAll to true by default on Mac was decided in bug 37587. 
From comment 18:

>However: On MSWindows and NT the behaviour in NC4.* is indeed to select the
>whole text in URL-field on first click. I tested it on a Windows-PC and even
>liked it. Mac acclaimedly also behave like that.

But they never bothered to verify that Mac NC4 acclaimedly [sic] worked like
that. It doesn't.  Upgraders *will* be confused.  

What's more, this behavior is a significant violation of Apple HIG:

http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/AHIGUserInput/index.html

Yeah, you give up some functionality by following HIG, but you get more back.
The issue of whether GUI standards are a good thing on the mac was decided a
while ago.  

Additionally, we have Command-L to achieve the current behavior without
violating HIG.
URL: http://developer.apple.com/techpubs/m...
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Click in URL field selects entire field → browser.urlbar.clickSelectsAll should default to false on Macintosh
Um say what?  Netscape 4.x on the Mac _does_ seelct the entire URL field when
you click in it if it doesn't already have focus.  You may be confused by the
fact that in Mac 4.x the URL field has focus when a page is loaded while the
content area starts with focus in Mozilla.
Ah, right.  Geez, subtle difference, big effect.  What I did on NS4 was to load
up a page by typing in the URL, scroll all the way down, and all the way up,
then click to edit the URL.  No auto-select, as expected.  Sure enough, if I
click in the content area first it does auto-select.  I must tend to view alot
more than I interact.  OK, there's not a 1:1 mapping here.
*** Bug 160742 has been marked as a duplicate of this bug. ***
There's much argument that clickSelectsAll violates HIG, but lots of people seem
to like it.  With bug 62495 fixed and if bug 116441 is fixed, 99% of the people
who are upset about clickSelectsAll on the Mac should be happy, without losing
the feature. 

If bug 116441 gets fixed, this should be marked WONTFIX so we can document,
"yeah, we know we're violating HIG, but we're doing it to add a feature and
we're not really ruining the Aqua experience in the oh-so-clever way we did it."

A bug recently marked as a dup of this one was titled, "Highlighting URLs in
location bar is infuriating," so some people are clearly still viscerally upset
about the current behavior.

Changing OS field from All to 8.6, since this is Mac OS-only.
Blocks: 73812
Depends on: 116441
OS: All → Mac System 8.6
Sorry, "There's much argument" above should say, "There's not much argument".
bug 116441 was fixed.

Marking WONTFIX to indicate that Mozilla is going to select the URL on click in
the URL itself, HIG be dammed.

If there's an rfe bug for a pref UI that somebody knows about, please make a
note here (couldn't find one).
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX
*** Bug 183330 has been marked as a duplicate of this bug. ***
Since UI consistency is one of the most important usability issues, it's not a bad idea to look at 
some other Macinosh web browsers.

Browsers that obey the HIG:
Camino
OmniWeb
Safari
Shirra
TrailBlazer

Browsers that select all:
Internet Explorer
Mozilla

iCab keeps track of the selection or cursor location in the location box even when it 
doesn't have focus and returns it to the previous selection or cursor location when clicking there.

I didn't test Opera because it expired on me. All these test where performed on Mac OS X 10.3.4 
Panther.

Mozilla's behavior is inconsistent with the HIG, inconsistent with the majority of Mac OS web 
browsers, inconsistent with *every* Mac OS-only web browser, inconsistent with other text boxes in 
Mozilla, and inconsistent with other text boxes on the Mac OS. It is, however, consistent with the 
defunct Microsoft Internet Explorer for Mac.
The people who like it can turn the pref back on.  It is a pref after all.

In the mean time, you're scaring the hell out of new users who expect it to
behave like every other Mac application.  There's a reason the Aqua HIG exists.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
OS: Mac System 8.6 → MacOS X
QA Contact: claudius → bugzilla
There's two options here. The first, attached, is to set the appropriate value
for clickSelectsAll, and leave the bits about browser.urlbar.clickAtEndSelects
intact. The second (forthcoming) removes those bits, effectively replacing bug
116441.

As far as I can tell, that was the only use of browser.url.clickAtEndSelects.
However, we may want to leave the infrastructure there and just change the
default preference, so that someone can set her preferences (as they exist now)
if she so desires.
Comment on attachment 166499 [details] [diff] [review]
patch (set browser.urlbar.clickSelectsAll to false on Mac)

Requesting r/sr. This is my first patch... please advise if I'm not following
protocol correctly.
Attachment #166499 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #166499 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 166499 [details] [diff] [review]
patch (set browser.urlbar.clickSelectsAll to false on Mac)

In general, I prefer more context (cvs diff -u9 file.js) but this change
doesn't need it.
Attachment #166499 - Flags: review?(neil.parkwaycc.co.uk) → review+
Well as I understand it there are three behaviours at work:
1. A simple click on the URL text selects it all.
2. A drag-selection on the URL text works normally.
3. If the URL is wholly displayed, then a simple click at the end of the URL
places the caret there rather than selecting it all.
If one of these isn't working, then I will agree that it is a bug. But I won't
claim to know why the Mac guys requested these particular behaviours.
(In reply to comment #14)

> However, we may want to leave the infrastructure there and just change the
> default preference, so that someone can set her preferences (as they exist now)
> if she so desires.

Yes, I agree, the preferences should stay.  Looking at all this argument on the
bug is enough testament that there are folks who Like It That Way.  But the
defaults should match the Aqua HIG on Mac.  (i.e. a single-click in either place
should not select anything, but only place the caret where you clicked)
Comment on attachment 166502 [details] [diff] [review]
patch (set browser.urlbar.clickSelectsAll to false on Mac and remove browser.url.clickAtEndSelects bits)

obsoleting per general consensus.
Attachment #166502 - Attachment is obsolete: true
Comment on attachment 166502 [details] [diff] [review]
patch (set browser.urlbar.clickSelectsAll to false on Mac and remove browser.url.clickAtEndSelects bits)

obsoleting per general consensus.
Comment on attachment 166502 [details] [diff] [review]
patch (set browser.urlbar.clickSelectsAll to false on Mac and remove browser.url.clickAtEndSelects bits)

obsoleting per general consensus.
Comment on attachment 166502 [details] [diff] [review]
patch (set browser.urlbar.clickSelectsAll to false on Mac and remove browser.url.clickAtEndSelects bits)

obsoleting per general consensus.
Whoa! sorry about that... some crazy back button foo just happened.

(In reply to comment #18)
> If one of these isn't working, then I will agree that it is a bug. But I won't
> claim to know why the Mac guys requested these particular behaviours.

Quoting Apple's HIG [1]:

  In text fields, clicking should perform the following actions:

  * Single-clicking places the insertion point at the pointer’s location in the text.
  * Double-clicking within a word selects the word. The selection should provide “smart” behavior; if the 
user deletes the selected word, for example, the space after the word should also be deleted.
  * Double-clicking in a space selects the space.
  * Triple-clicking selects the next logical unit, as defined by the application. In a word-processing 
document, triple-clicking in a word selects the paragraph containing the word.

With this patch, our default behavior is correct for all but the bit about double-clicking a space. (I'll file 
a 
bug about that, if there's not one already.)

[1] http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/
XHIGUserInput/chapter_2_section_4.html#//apple_ref/doc/uid/TP30000361-TPXREF27
URL: http://developer.apple.com/techpubs/m... → http://developer.apple.com/documentat...
Status: REOPENED → ASSIGNED
Assignee: firefox → lbenne01
Status: ASSIGNED → NEW
Really accepting the bug this time, I swear! (Sorry for all the spam.)
Status: NEW → ASSIGNED
Product: Core → Mozilla Application Suite
Comment on attachment 166499 [details] [diff] [review]
patch (set browser.urlbar.clickSelectsAll to false on Mac)

jag, you shouldn't have admitted to having a Mac ;-)
Attachment #166499 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview?(jag)
Whiteboard: fix-in-hand
So, I guess you have done some usability tests in order to patch/review this
pref change.

As this patch affects firefox as well, you should double check this against
firefox ui owners before you land it.
(In reply to comment #27)
> So, I guess you have done some usability tests in order to patch/review this
> pref change.

FWIW, and I realize the question may have been rhetorical, Apple *does* do this
kind of testing and Safari's behavior would be the result of said testing.  Lord
knows Apple doesn't mind violating HIG where it feels like it.
(In reply to comment #28)
> (In reply to comment #27)
> > So, I guess you have done some usability tests in order to patch/review this
> > pref change.
> 
> FWIW, and I realize the question may have been rhetorical, Apple *does* do this
> kind of testing and Safari's behavior would be the result of said testing.  Lord
> knows Apple doesn't mind violating HIG where it feels like it.

haha (for your information readers, safari disable tabbed-browsing by default).

Now, i don't see how we /really/ violate the HIG here. The urlbar isn't a
general textbox - far from; the pref doesn't apply general textboxes, if it did,
we would violate window/gnome HIG as well. If I follow the reasons mentioned
here, we should disable autocomplete as well.

clickSelectAll is an (pretty good) answer to the following usability issue well
described in mpt's blog ( http://mpt.net.nz/archive/2004/02/16/os-x ):

"28. Clicking once in the address field does not do what people want 99 percent
of the time, which is selecting the address so it can be replaced by typing a
new one. (This can be done without interfering with those who want to select
only part of the address, as demonstrated by Firefox and by Internet Explorer
for Mac.)"


> Now, i don't see how we /really/ violate the HIG here. The urlbar isn't a
> general textbox - far from; the pref doesn't apply general textboxes, if it did,
> we would violate window/gnome HIG as well. If I follow the reasons mentioned
> here, we should disable autocomplete as well.

Regardless of the HIG, Mac OS X users expect clicking in any text input box to immediately place the 
cursor where they click, not to select the contents of the box. This is true in every OS X program I know 
of, including every OS X browser except Moz and Firefox (even Camino gets it right). The autocomplete 
issue is a different bug.

> clickSelectAll is an (pretty good) answer to the following usability issue well
> described in mpt's blog ( http://mpt.net.nz/archive/2004/02/16/os-x ):

mpt is not describing a usability issue here. He's whining about OS X not behaving the same way as 
whatever OS he's used to (I'm guessing Windows). 
(In reply to comment #27)
> As this patch affects firefox as well, you should double check this against
> firefox ui owners before you land it.

The equivalent Firefox bug is bug 233977.
> Regardless of the HIG, Mac OS X users expect clicking in any text input box to
immediately place the 
> cursor where they click, not to select the contents of the box. This is true
in every OS X program I know 
> of, including every OS X browser except Moz and Firefox (even Camino gets it
right).

You're still not explaing how OS X is different from Windows/* in this case, the
behavoir you request is the *general behavior in any os* for normal textfields.
While i'm pretty against a "fix" for this bug, this is an all/all one, not mac
specific.

> The autocomplete issue is a different bug.

next time, i'll add "joke joke".

> > clickSelectAll is an (pretty good) answer to the following usability issue well
> > described in mpt's blog ( http://mpt.net.nz/archive/2004/02/16/os-x ):
> 
> mpt is not describing a usability issue here. He's whining about OS X not
behaving the same way as 
> whatever OS he's used to (I'm guessing Windows). 

Have you read the page? or just the paragraph I quoted (I'll let someone else to
tell you which OS mpt is using ;) ).
(In reply to comment #31)
> (In reply to comment #27)
> > As this patch affects firefox as well, you should double check this against
> > firefox ui owners before you land it.
> 
> The equivalent Firefox bug is bug 233977.

all.js is used by both seamonkey and firefox/thunderbird; if another bug is
filed , it's (more or less) a dupe.

(In reply to comment #32)
> While i'm pretty against a "fix" for this bug, this is an all/all one, not mac
> specific.

Wait, I must be missing something.  The title and hardware/os are set to Macintosh by the patch 
doesn't look mac-specific.  Shouldn't this be in an overlay of some kind?  Somebody tell me I'm dumb 
and blind and missing a mac-specific #ifdef.

ClickSelectsAll is the expected behavior for Windows users, e.g.
(In reply to comment #34)
 
> Wait, I must be missing something.  The title and hardware/os are set to
Macintosh by the patch 
> doesn't look mac-specific.  Shouldn't this be in an overlay of some kind? 
Somebody tell me I'm dumb 
> and blind and missing a mac-specific #ifdef.
> 
> ClickSelectsAll is the expected behavior for Windows users, e.g.

The patch does change the mac specific section; if it wasn't clear: There is
nothing special [i know of] in Aqua HIG that makes this bug mac-specific (please
ready my previous comment again before replying, thanks).


> Now, i don't see how we /really/ violate the HIG here. The urlbar isn't a
> general textbox - far from; the pref doesn't apply general textboxes, if it did,
> we would violate window/gnome HIG as well.

Other non-general text boxes that behave as this bug suggests include the
Finder's and iTunes' search text boxes.

> clickSelectAll is an (pretty good) answer to the following usability issue well
> described in mpt's blog ( http://mpt.net.nz/archive/2004/02/16/os-x ):

This may be true in general, but its utility is belittled when its behavior is
inconsistent with the rest of the operating system. With all due respect to mpt,
I'm more inclined to refer to the HIG itself (than to mpt's blog) for details
about Aqua compliance.

This will fix bug 233977; marking dependency, unless someone would rather it be
a dupe. Either way, can someone tend to the sr of the patch? It's been sitting
there since 11/04.
Blocks: 233977
No longer blocks: 233977
*** Bug 233977 has been marked as a duplicate of this bug. ***
Component: XP Apps: GUI Features → XP Toolkit/Widgets
Product: Mozilla Application Suite → Core
Asaf, I am totally confused by your responses. First you say that the fix is "an all/all one, not mac
specific." Then you say that the patch changes "the mac specific section". Then you say that "there is
nothing... that makes this bug mac-specific." Please clarify what you mean.
I will try another time:

This bug (and the attached patch) requests to change a behavior *only on mac*
based on a HIG guideline (which i'm not sure it's a valid argument here, the
urlbar is not a general textfiled) which is NOT mac specific. From my POV, this
makes the request _invalid_.

Both Seamonkey and Firefox are not in a beta stage, you can't change a default
based on your opinion - unless you (or someone else) provide usability stats
which show mac users prefer the urlbar not to work this way (clickSelectAll) 

Further more, IE5:Mac was the default OS X browser until 10.2.x which did behave
this way (clickSelectAll in the url bar); you're affecting the user experienc of
its [former] users as well.
Correction: This patch doesn't affect Firefox which resets the pref in
firefox.js (which overrides some prefs from all.js).
I'll agree that a case would be stronger given usability tests to backup the
claim: this bug is a good one for someone who wants to run said test. I don't
have access to a pool of mac users to test, so that person ain't me. Reassigning.
Assignee: bmo → jag
Status: ASSIGNED → NEW
QA Contact: bugzilla → jrgmorrison
Whiteboard: fix-in-hand → fix-in-hand, needs usability testing (see comment 39)
(In reply to comment #39)

> Further more, IE5:Mac was the default OS X browser until 10.2.x which did
> behave this way (clickSelectAll in the url bar); you're affecting the user
> experienc of its [former] users as well.

This is outright not true.  I just tried it.  IE:Mac 5.2 places the insertion
point at the spot you click when you single-click in the URL bar.

Safari also does the same.

So does iCab.

So does OmniWeb.

So does Camino.

Mozilla and Firefox are the ONLY browsers for Mac OS X that do a click-selects-all.
That's not what i understand from both comment 12 and mpt's blog, but i am not
able to test it right now.
Attachment #166499 - Flags: superreview?(jag)
macIE 5.2 selects the entire url when you click it. i just tried it.
(In reply to comment #44)
> macIE 5.2 selects the entire url when you click it. i just tried it.

It most certainly doesn't on my copy.  Wonder if IE has it as a user pref, too?

/me looks

Yep.  Internet Explorer > Preferences > Interface Extras > "First click on the
address field".  Mine's set to "places the insertion point".  The other option
is "selects all the text".

Now the question is which one is default?  I certainly don't remember changing
it, but I've had a Mac for years with this same user account data.
Obviously, just because IE/mac does something doesn't mean it's the right thing
to do. This bug exists because many of us believe that its behavior violates the
Aqua HIG. In fact, whereas usability testing would clarify if one behavior is
better than the other, I think the philosophy of comment 13 is much more on
track. We should err in favor of the behavior laid out by the Aqua HIG,
performing usability testing to see if Mozilla/Firefox's current (arguably
erroneous) implementation makes things better or worse.
Keywords: polish
> Now the question is which one is default?  I certainly don't remember changing
> it, but I've had a Mac for years with this same user account data.

Selecting the entire URL is the default behavior.
Defaults and other apps aside, I *really* like having this pref set the other
way (click places insertion point rather than select all).

If I want to load a url, I very rarely type it in.  Typically I will drag and
drop it to the browser window or click on a link or copy the url and paste it
into the url (after setting focus in the url and triple-clicking or command-A).
 More common for me is to edit the URL to remove part of the url or add an
additional part.  Disabling the clickSelectsAll pref makes this last part work
*MUCH* better.

Do most people really type a complete url or are they surfing with a mouse or ?
brade, i'll ask you as well: how is your comment mac-specific related? I assume
you prefer this defalut on windows too, don't you?
Comment on attachment 166499 [details] [diff] [review]
patch (set browser.urlbar.clickSelectsAll to false on Mac)

The patch fixes the behavior described in comment 0. Let's get sr, discussing
its merits from a global standpoint all the while. As I understand it, the two
processes are not mutually exclusive.
Attachment #166499 - Flags: superreview?(jag)
Comment on attachment 166499 [details] [diff] [review]
patch (set browser.urlbar.clickSelectsAll to false on Mac)

and for the coding issue.. this will never work, browser-prefs overrides you.
Asaf (comment 49) -- I'm a Mac person.  If I have a choice, a Windows computer
would be a Macintosh and run Macintosh software (written by me ;-) ).

You are correct that my question is a general question about overall use of the
urlbar and not necessarily specific to a particular platform.

Note: this bug is 3 years old.  It was created before Camino/Firefox/Safari. 
The original comment in this bug certainly was valid given the era.  Did
Camino/Firefox/Safari just copy Mozilla?  Does any of it really matter?

I truly believe the pref is set wrong but I acknowledge that I haven't done a
usability study to show how people do use the URL bar (if at all).  I can't
really say if it is platform-specific or not.

For now, I think the existing patch should be super-reviewed and other bugs can
be filed for making it fixing the other platforms or fix only Windows or whatever.
<bug-advocacy-spam>
This bug is such a no-brainer. I can't understand why there is any controversy.
Let me reiterate the case for this bug:
In Mac OS, every text field in every program (regardless of whether it is an
official "textbox" or not) operates in a standard way. This is more than an HIG
or a written standard, it is a long-standing and universally adopted convention
of Mac OS. The whole idea of Mac OS is that programs are supposed to use the
same interface conventions -- the same command keys, a standard set of menus,
the same window widgets, standard behaviors for contextual menus, drag-and-drop,
etc. This is what is supposed to set Mac OS apart from Windows, Linux, and the
rest. Users of Mac OS are spoiled and expect their programs to conform to
certain standard interface behaviors. One of those behaviors is that when you
click on editable text it places an insertion point where you click. This has
been true since the first version of Mac OS twenty years ago. I can tell you for
a fact that the current behavior of Mozilla and Firefox is frustrating for Mac
users, as this bug makes me curse Firefox every time I encounter it, which is a
few dozen times a day. And despite the fact that I use Firefox for 8 hours a
day, 5 days a week, I cannot get used to its address bar behavior. In the world
of Mac OS, it is an interface abomination. It sticks out like a sore thumb.
Every time I click on the address bar, it feels like I'm using a program from
another OS and I feel dirty inside. This IS a Mac-specific bug because Mac users
expect a different behavior; Windows users do not. You can waste a year talking
about usability tests if you want, but I can already tell you what the result
will be. Let's fix this bug and be done with it.
</bug-advocacy-spam>
I don't know if it's too late, but it would be most excellent to get this into 1.8b.
Flags: blocking1.8b?
I think it's obvious by now that that no-one's going to do a full-fledged
usability test to decide the fate of this bug. What *can* serve as an
alternative test, is to log users' behavior when clicking the URL bar.

* Do they triple click? 
* Do they triple click at first, then click only once in the next times they
want to type a URL?
* Do they drag-select?
* Do they click at the end of the URL?
* When they trim a URL, do the click the insertion point, or do they drag-select
then delete?

These and other usability questions can be answered by releasing a few builds
that log the URL-clicking behavior of Mac users. 

For more on this idea, see Bug 273241 - "Better default prefs through machine
learning (add logging facility to help decide usability issues)"

Prog.
Depends on: 273241
I agree. In the mean time, as I argued in comment 46, I think it's best to err
on the side of apple's HIG.
I think in the meantime it's better to not break it if it's not unanimously
considered to be broken.

Prog.
I mentioned this once before, but I'll mention it again: this feature has been usability tested.

By Apple.  For Safari.

IE was the OSX browser and it did clickSelectsAll by default.  For Safari they made a conscious decision 
to change that behavior, and Apple doesn't do that "just 'cuz" - they're very big into usability testing.  
Additionally, the Safari beta included a distributed usability test where users were encouraged to report 
issues with the browser and this behavior wasn't changed during the beta period or since.  See this 
paper for some more description:  http://opensource.mit.edu/papers/nicholsmckaytwidale.pdf 

Just saying, "we're not going to fix this until there's a usability test" is just throwing an obstacle in the 
way and is intellectually dishonest .  If someone wants to argue that Apple's testing was flawed, go for 
it.

So it's not that there hasn't been a usability test, it's that some people here don't accept it or have Not-
Invented-Here syndrome.  The onus should be on those people to prove via their own usability test that 
they're right and Apple is wrong.  In matters related to HIG the accepted pattern in MacOS software 
development is to defer to Apple unless there's a strong reason not to.
just because Apple releases software means they've done extensive usability
testing. Most of the time they do things because Steve Jobs said so, not because
they have any data to back it up from running a study. Do you know for sure they
did UI testing for safari (and a public beta doesn't count).

that said, you know what my preference is (from Camino).
> With all due respect to mpt, I'm more inclined to refer to the HIG itself
> (than to mpt's blog) for details about Aqua compliance.
With all due respect to the Apple HIGs, Apple have repeatedly changed them 
in (largely unsuccessful) attempts to rationalize increasingly arbitrary 
design decisions (for example, the use of brushed metal).

> the Safari beta included a distributed usability test
That is not true. As even the link you provided points out, the bug 
reporting tool was "to help the developers identify web pages that do not 
display correctly". Misrepresenting that work, and misrepresenting those who 
disagree with you as saying "we're not going to fix this" when it's a matter 
of opinion rather than a bug; *that* is intellectually dishonest.
(In reply to comment #60)
> That is not true. As even the link you provided points out, the bug 
> reporting tool was "to help the developers identify web pages that do not 
> display correctly". Misrepresenting that work, and misrepresenting those who 
> disagree with you as saying "we're not going to fix this" when it's a matter 
> of opinion rather than a bug; *that* is intellectually dishonest.

Umm, I used the Safari bug reporting tool to report UI issues during the beta period.  You do "Problem 
type: behavior wrong, or 'other'" (and they got fixed).  But that's off-topic.

Conforming with HIG is not a matter of opinion, it's a matter of good Mac programming.  
Deviating from HIG is what requires a decision/opinion.  When someone declares "we're not going to do 
this unless someone does a usability study" it's as good as saying, "we're not going to fix this";  a good 
study costs about 5 grand for a small test.  This is a reasonable approach when you're talking about 
violating HIG, perhaps for a good reason.

Mike Pinkerton asked if I knew if Safari had any usability testing.  I don't work at Apple and would 
probably be violating NDA if I knew specifically, but last time I talked to developers at WWDC the Apple 
HIG group had been disbanded proper and each application team had received at least one HIG 
designer who was tasked with UI design and testing for his app.  I have no specific knowledge as to 
whether the Safari team was an exception to this rule or if they've subsequently fired the guy or his job 
description has changed, but it's an educated guess based on how things commonly work there.
Flags: blocking1.8b? → blocking1.8b-
Is this fixed now?  The URL Bar in the Bon Echo nightly on this Mac OS X 10.4.5 seems to work as described.  Or am I misunderstanding the bug?
I agree, I'm running Bon Echo 20060410 and it works correctly (yay!).

I'll mark it fixed and if this is going to regress for any reason we can REOPEN it.

It would be nice if it were noted here when and how this got fixed before it's VERIFIED.  It might need to be duped against another bug.
Status: NEW → RESOLVED
Closed: 22 years ago → 18 years ago
Resolution: --- → FIXED
No explanation given as to how it got fixed.

-> WORKSFORME
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → WORKSFORME
Hmmm - I think I made a mistake marking this RESOLVED.  REOPEN'ing.

Where this got fixed for Firefox users was bug 233977 - a Firefox/Toolbars bug which addresses this in firefox.js.  But this bug is about all.js.  In firefox.js, this gets handled by an #ifdef XP_UNIX:

  http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=firefox.js&branch=&root=/cvsroot&subdir=mozilla/browser/app/profile&command=DIFF_FRAMESET&rev1=1.60&rev2=1.61

but in all.js, XP_MACOSX is specifically #ifndef'ed out of XP_UNIX preferences (where this is set to false for other Unix systems):

http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js#1807

It looks like the patch which has review will still apply, so we're back to needing superreview.  Rationale is well-established at bug 233977.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Well, this had been fixed during Firefox 2.*. The URLBar behaved as one would expect and followed the conventions of clicking in other Mac applications. However, as of 3.0b4rc2, this is broken again. It now behaves totally unexpectedly and I had concluded it was utterly broken until I saw the pref name in this bug report. By the way, I handed this laptop with b4rc2 on it to two non-computer-savvy mac users in the house and within a few minutes, both concluded that *Firefox* was broken and asked what was wrong with it.

This isn't going to be seen as a feature by general users, it's going to be seen as infuriating breakage. Those are the same general users who wouldn't be able to change the pref via about:config
I found this BZ ticket because I noticed that firefox 3 is broken in
this respect (a single click in urlbar *or search bar* selects all the
text).  I changed browser.urlbar.clickSelectsAll to false, which fixed
the urlbar, but the search bar still has the broken behaviour; I can't
find a preference that would seem to apply.  Please consider both url
bar *and* search bar when you patch this.  (And if anyone can tell me
how to turn off clickSelectsAll for the search bar in the meantime I'd
be very grateful.)

Curiously I found that after a restart the search bar now also obeys the
new browser.urlbar.clickSelectsAll value, so I'm happy again.  Maybe
the intitial change could be propogated to both bars without requiring
a restart?

Not that John Gruber's opinion should be treated as canon, but there's a lot of people that share his opinion (including me).  http://daringfireball.net/2008/04/firefox_3_safari_3
Flags: blocking1.9?
This is not a layout bug. It's not even a toolkit bug, is it? It should be a browser bug.
Assignee: jag → nobody
Status: REOPENED → NEW
Component: XP Toolkit/Widgets → Location Bar and Autocomplete
Flags: blocking1.9?
Flags: blocking1.8b-
Product: Core → Firefox
QA Contact: jrgmorrison → location.bar
This will not block the final release of Firefox 3. Any patch will need unit tests in order to be approved.
Flags: blocking-firefox3? → blocking-firefox3-
I don't think it has much to so with what people plan to do with the field once they get to it, but more with how people expect it to behave.  Mac users expect a single-click to drop the insertion point, and are used to triple-clicking or hitting Command-A to select all. Violating that assumption (even though you're trying to cater to what people are most likely to do with that field) only confuses people.
this is definitely the wrong direction. now favicon has lost the capability of single click to select url, how do users supposed to select url easily?

Not everything "mac-ish" is good, it is a stupid idea to remove the only single-click-select function firefox 3 has.

Mac people? how many mac people are there? 50% of mac people are windows switchers. they are new, they have NO expectations!

Do some user feedback poll and study, don't do foolish things, you can behave like safari and try to beat safari. You do what users need.
(In reply to comment #73)
> this is definitely the wrong direction. now favicon has lost the capability of
> single click to select url, how do users supposed to select url easily?

Hmm, favicon still selects everything for me, and I have clickSelectsAll disabled right now.  Of course, you have to double-click it instead of single-click, because a single-click brings up Larry.

> Not everything "mac-ish" is good, it is a stupid idea to remove the only
> single-click-select function firefox 3 has.

If you really like it, you can turn it back on just as easily as those of us that prefer it off have turned it off.

> Mac people? how many mac people are there? 50% of mac people are windows
> switchers. they are new, they have NO expectations!

People switch to Mac because the Mac is consistent and easy to use because of that consistency.  People expect things to work like they do everywhere else in the OS.

(In reply to comment #73)
> Mac people? how many mac people are there? 50% of mac people are windows
> switchers. they are new, they have NO expectations!

Hand a 3.0 beta to a typical user who's had a mac for more than a month and they're going to conclude that Firefox is broken because it is the only app they have that doesn't behave like all of the other apps.


> Do some user feedback poll and study, don't do foolish things, you can behave
> like safari and try to beat safari. You do what users need.
> 

It's not just Safari, it's the OS default way of interacting with a text box. The user isn't going to think "Hey, thank god Firefox fixed this stupid way Safari behaves!" they're going to say "Hey, Firefox is frustrating to use because it doesn't behave the way the Finder, MS Word, iChat, Pages, Photoshop, Adium, Mail, etc behave!".

I've rolled out 3b4 to some of the users I support because it fixes an important bug for is in FF2*. They all asked me the next time I was in why the URL bar was broken.

im sure both side have arguments, so, do a survey or study to see which side should weigh more.
Also, I have used MB as my main machine for 2 years, so you know im not making comment out of my league.
Is a survey really necessary?  Isn't it clear that the UI guidelines
under mac os x are there for a good reason, and that being the odd-
one-out application that *doesn't* follow them makes no sense?  Sorry
if I'm being obtuse, but I don't really see why "it's what we do on
windows" should trump ("it's how macs work").  [snarky] If that *is*
the case, then maybe the mac version should be rewritten to remove
its menus from the mac menu bar and instead stick a copy of each menu
at the top of each browser window, because that's how windows does
it? :) [/snarky]

This is a very basic usability issue for Mac users. This behavior is annoying enough to have forced me to downgrade back to Firefox 2. Mac users expect their programs to behave consistently. Firefox 3 is broken in this regard. If you want to drive Mac users from Firefox to Safari, this bug will do it. Should be a blocker, IMO, but just my 2 cents.
This whole thread is completely ridiculous. Was there a user study, when the behaviour changed for FF2, and then again for FF3? Who made the initial decision and on what user study was this based?

It is quite obvious what is the correct and expected behaviour on the Mac. It's also quite obvious what's the correct and expected behaviour on Windows. Personal preferences don't count (I have a very strong personal preference, but I'm not going to tell you what it is :) ).

Consistency with the rest of the OS is a very important thing when designing any application. Breaking consistency has to be a deliberate and well thought out decision, and it has to be shown that it really provides a better user experience. This might be done through a user survey or study for example.

OTOH, fixing a consistency issue which came from i_dont_know_where, does NOT require a user study. NOT fixing it might require one, but as this is not going to happen soon, as seen by the age of this thread, just fix it and get it over with.

And if you don't already know it (but you all do, do you?) read http://www.bikeshed.com/
Marc
Status: NEW → RESOLVED
Closed: 18 years ago → 15 years ago
Resolution: --- → DUPLICATE
Why is this suddenly closed after several months without any further comment? Has anything happened in the mean time, for example the before mentioned user study, and if so, could we please know about it?
(In reply to comment #85)
> Why is this suddenly closed after several months without any further comment?
> Has anything happened in the mean time, for example the before mentioned user
> study, and if so, could we please know about it?
This bug was marked as a duplicate, so you should look to bug 409810 for the reasoning.
And what about the reasoning here?
(In reply to comment #87)
> And what about the reasoning here?
You are welcome to make that argument there.
Comment on attachment 166499 [details] [diff] [review]
patch (set browser.urlbar.clickSelectsAll to false on Mac)

Dropping request for long-closed bug.
Attachment #166499 - Flags: superreview?(jag-mozilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: