Closed Bug 37587 Opened 25 years ago Closed 23 years ago

Clicking in address field (URL bar) should select contents

Categories

(SeaMonkey :: UI Design, defect, P2)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: randolph, Assigned: bugzilla)

References

Details

(Keywords: access)

Attachments

(2 files)

patch (this is so lame)
3.32 KB, patch
Details | Diff | Splinter Review
patch w/ focusSelectsAll changes
4.72 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m15)
BuildID:

When a text field with text in it is first selected, the text cursor appears
where ever the click in the field is made.  A more common, and in my opinion,
more useful behavior is to select all of the text already in that field.

Reproducible: Always
Steps to Reproduce:
1. Just click in the URL field at the top of a mozilla window
	

Actual Results:  Text cursor appears where the click was.

Expected Results:  All text in the field selected.

This is standard behavior on MacOS and MS-Windows.
I really prefer the cursor to be inserted where i click and no selection to
automatically trigger. That's what double-clicks are for. When i click once in
URL field nowadays it's usually to alter bugnumber at the end of url. Would be
annoying if i had to click once more to deselect first.

This is not a bug however: Selections have never happened the described way in
Moz till now.

Chancing severity to enhancement.
Severity: normal → enhancement
I don't agree that all textboxes should fully highlight upon focus, that can be 
confusing, annoying and unexpected.  However, as was the standard in NS 4.72 
and IE, I do think the URL bar should be selected upon gaining focus ( though 
this may have been reported already ).
->Editor
Changing this to an enhancement, cc'ing mjudge (selection)
Status: UNCONFIRMED → NEW
Component: User Interface: Design Feedback → Editor
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All
Summary: Text field selection behavior awkward → [RFE] Highlight /Select contents of URL bar upon focus
"I don't agree that all textboxes should fully highlight upon focus, that can be 
confusing, annoying and unexpected."  Hunh?  It is standard in Windows and
MacOS, as far as I know.
Perhaps it's standard behavior in Win32 for a textbox to automatically have the 
focus upon initialization in, say, a dialog, however it's definitely not 
typical behavior to highlight the entire contents of a textbox when you click 
within it/set focus to it...
"it's definitely not typical behavior to highlight the entire contents of a
textbox when you click within it/set focus to it."

I just spent a few minutes with MacOS testing this.  You are right; the behavior
(at least on MacOS) is a good bit subtler.  As far as I can tell, upon a dialog
gaining focus there is always an indicated text field, which will be selected. 
Clicks within other text fields in that dialog box will usually simply place the
text cursor at the appropriate place within the field.  However, if one TABs
from field to field, each field is selected in its entirety as it is entered,
apparently on the assumption that the user is most likely to want to type a new
value in that field if the user changes that field.  I don't know how much
testing was done on that design; it seems to me "reasonable," but that could
just be familiarity talking.  Since I'm not currently at school, I can't test
MS-Windows, however I believe the behavior is similar except that Windows by
default will also allow one to tab to an arbitrary control.
For just any old text entry widget, clicking in it does not select its contents 
on either Windows or MacOS. (I just checked.) Tabbing to a text widget, or giving 
it focus by any means other than clicking in it (such as getting focus in a 
newly-opened window) normally *does* select the widget contents, but that is 
covered by bug 28583.

The location bar could be seen as a special case, where a single click selects 
the entire contents. But that was discussed in netscape.public.mozilla.ui
<http://www.deja.com/=dnc/viewthread.xp?AN=607131090>, and it doesn't seem to be 
a good idea -- as long as there is a convenient keyboard shortcut for tabbing to 
the location bar, which would select the entire contents just like it would for 
any other text entry widget.

Single click to insert the cursor in a text field is standard behavior.  You're 
using a pointer to indicate where you'd like to start typing.  If you want to 
overwrite existing text, you can click and drag a specific section or double 
click for the whole thing.

The URL field *could* be considered different, but that has the potential to 
be confusing and even frustrating.  Consistent double-click/select-all 
behavior should be sufficient.

Resolving as invalid since the current design (pending bug 28583 being 
fixed) matches standards.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Verified invalid.
Status: RESOLVED → VERIFIED
*** Bug 38774 has been marked as a duplicate of this bug. ***
*** Bug 19217 has been marked as a duplicate of this bug. ***
*** Bug 49622 has been marked as a duplicate of this bug. ***
*** Bug 51580 has been marked as a duplicate of this bug. ***
Filed bug 52784, `Clicking in proxy icon area should select location field 
contents'.

*** Bug 26848 has been marked as a duplicate of this bug. ***
*** Bug 57299 has been marked as a duplicate of this bug. ***
*** Bug 57299 has been marked as a duplicate of this bug. ***
We have quite a few dupes here.  I'm sure there are a few out there that didn't
get marked dupes too like bug 59997 which could have been marked a dupe of this.
 Requesting we re-evaluate the Invalid resolution on this bug.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
I originally spoke against this RFE, but have changed my mind.
I'm too used to unix behaviour, where selection auto-copies, so the whole
feature would have been a pointless aggrevation, since whatever i pasted after
selecting URL field would be the same URL all over again.

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.

Adding keyword.
Keywords: 4xp
This is a bug for which I think people will disagree quite strongly about 
preferred behavior. For some people, typing completely new contents into the 
address field is what they do 99.9 % of the time, so single-clicking to select 
the field contents is worth the inconsistency with other text fields. But for 
others, those who often edit URLs in the address bar, the single-click-to-select 
behavior is extremely annoying.

In an effort to please both groups of people, I would like to see bug 28583, bug 
31809, and bug 52784, which would all make it easier to select the contents of 
the address field, implemented for a couple of months (so that Mozilla users can 
become familiar with those behaviors) before this bug is reconsidered.
Assignee: bdonohoe → ben
Status: REOPENED → NEW
Component: Editor → User Interface: Design Feedback
Depends on: 28583, 31809, 52784
Also bug 30864, which covers pressing Ctrl+Tab to focus (and select the 
contents of) the address bar.
Depends on: 30864
Adding bug 19446 (need keyboard shortcut to focus location bar) to dependencies.
Depends on: 19446
There's a half-working hidden pref now that selects the entire url when you 
click the location bar once.  Add this to prefs.js in your profile directory to 
try it:
user_pref("browser.urlbar.clickSelectsAll", true);

Currently, the pref selects the entire urlbar on mouseup instead of only on 
normal "clicks", so it's difficult to select a _part_ of the url.
<http://www.nytimes.com/2000/11/30/technology/30STAT.html>:

`The most alarming flaw, however, is that you can't highlight the entire
Address bar with a single click. You must highlight the current Web address
by dragging the mouse over it each time you want to type a new address, an
oversight blatant enough to make you wonder exactly how much time the
program's designers actually tested Navigator by, say, browsing the Web.'

Matthew, the 99% case is usually enough for you to go that way.  What's 
different about this?
This should remain defaulted to false on Unix -- it's infuriating to have the
urlbar selected, and we'll get lots of flames if we enable it since it will also
overwrite whatever was previously in the clipboard.

Previous feedback from Mac people said that they, too, wanted it defaulted off,
but if you think that has changed, maybe it's worth raising the issue on
mozilla-mac to see what people think.
Blake, if we can cater for the 100-percent case by fixing the dependencies of 
this bug (which are bugs that need to be fixed anyway), that's better than 
catering for the 99-percent case. But if the dependencies prove not to be enough, 
then fine, let's change the behavior.

(Also consider that reviewers, such as the one in the NY Times, may rely on 
typing URLs -- rather than bookmarks -- a lot more than they would with their 
usual browser, especially with Mozilla's current brain-dead treatment of IE 
favorites.)
Summary: [RFE] Highlight /Select contents of URL bar upon focus → [RFE] Click to highlight/select contents of URL field
Bug 62496 now tracks some problems that come up when 
browser.urlbar.clickSelectsAll is enabled.
Nominating for nsbeta1.
Keywords: nsbeta1
*** Bug 63881 has been marked as a duplicate of this bug. ***
Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
*** Bug 75523 has been marked as a duplicate of this bug. ***
Currently, only left-clicking selects the URL, even when 
browser.urlbar.clickSelectsAll is set.
IMO this should also happen when right-clicking, just as in NS4 and IE.
nav triage team:

There are too many issues here, when we can better articulate what this bug is 
supposed to mean, we will reconsider. We believe that one-click select all in URL 
is the correct behavior and believe that there is at least one other bug to 
addresss that issue. Marking nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Whoa Whoa Whoa, That has to be the most cryptic comment from the Nav Triage team
ever. 

>>There are too many issues here, when we can better articulate what this bug is
>>supposed to mean, we will reconsider. 

The only issue here is that a single click should select the entire contents of
the URL field. This is the behavior in Mac and Win NS4.x and IE. The bug is not
about focus/select related issues in any other textbox, those are other bugs.

>>We believe that one-click select all in URL is the correct behavior and 
>>believe that there is at least one other bug to addresss that issue. Marking
>>nsbeta1-

There is no other bug involving a single click to select the URL bar contents.
If there is, it is a dup of this bug. (trust me I've tried to find one) If NS
feels that this is the correct behavior, then they want to + this bug.

If someone with the power to do so could please remove the - to send this bug
back through triage it would be greatly appreciated (I can't do it myself)

Also, this bug should NOT refer to Linux/Unix, as selecting the URL bar would
cause some serious problems with pasting from the system clipboard. No app that
I know of (including NS4.x) in linux has this behavior. (and for good reason)
I'm pretty sure this bug is "enable the (hidden) clickSelectsAll pref by default".  There are still a few problems with the way Mozilla behaves when the hidden clickSelectsAll pref is turned on, however, which might make it so that fixing this bug would require more than just changing the default pref.  See bug 62496, "[meta] problems with browser.urlbar.clickSelectsAll behavior".  (Several of bug 62496's dependencies are currently targetted to mozilla0.9.1.)

On Linux, Ctrl+L selects the location bar contents without copying them to the clipboard.  I think it would be reasonable to do the same thing when clickSelectsAll is enabled and the user clicks in the location bar.  (If clickSelectsAll currently *does* blow away the contents of the clipboard on Linux, please file a bug and add it to bug 62496's dependency list.)
[reposting, hopefully with the text wrapped this time]

I'm pretty sure this bug is "enable the (hidden) clickSelectsAll pref by 
default".  There are still a few problems with the way Mozilla behaves when the 
hidden clickSelectsAll pref is turned on, however, which might make it so that 
fixing this bug would require more than just changing the default pref.  See 
bug 62496, "[meta] problems with browser.urlbar.clickSelectsAll behavior".  
(Several of bug 62496's dependencies are currently targetted to mozilla0.9.1.)

On Linux, Ctrl+L selects the location bar contents without copying them to the 
clipboard.  I think it would be reasonable to do the same thing when 
clickSelectsAll is enabled and the user clicks in the location bar.  (If 
clickSelectsAll currently *does* blow away the contents of the clipboard on 
Linux, please file a bug and add it to bug 62496's dependency list.)
Ok, let's do this. Blake was right, I was wrong. Selecting the field contents 
might be annoying for the tiny minority of users (like me) who edit existing 
URLs more often than entering new ones, but them's the breaks. And it sure 
isn't worth having a pref for, that would be laughable.

Things which should happen in order for this bug to be marked fixed:

(1) If (and only if) the address field does not have focus, hovering over it
    should use {cursor: default}, not the {cursor: text} usually used for text
    fields. This indicates that clicking in the field will behave differently
    from a normal text field.

(2) On mousedown of the primary (e.g. left) mouse button, the cursor should
    change to {cursor: text}. This indicates that text can be selected with the
    mouse down, just as it can be for any other text field.

(3) On mouseup, if (and only if) the cursor position never changed between
    mousedown and mouseup, the entire contents of the address field should
    become selected. This way, the click-to-select behavior will not interfere
    with selection.

(4) All traces of the browser.urlbar.clickSelectsAll pref should be removed.

(5) If (and only if) the address field does not have focus, on mousedown (not
    mouseup) of the secondary (e.g. right) mousebutton, the entire contents of
    the address field should become selected, and the normal text field context
    menu should open.

--> XP Apps: GUI Features.
Assignee: ben → blakeross
Severity: enhancement → normal
Component: User Interface Design → XP Apps: GUI Features
No longer depends on: 19446, 28583, 30864, 31809, 52784
QA Contact: zach → sairuh
Summary: [RFE] Click to highlight/select contents of URL field → Clicking in address field (URL bar) should select contents
No.

On Unix, single click has never selected the URL bar contents.  It should not. 
I don't much care if it's a pref or a platform check (though I think many
Mozilla users on non-Unix platforms would appreciate the ability to edit the
contents of the URL bar without contortions), but we _cannot_ change the
behaviour of the URL bar single-click on Unix.

Why would we want to?  The article that Blake cited, while nicely inflammatory,
was certainly not written by a Unix user.  I think we should absolutely match
4.x and other-browser behaviour on Windows and Mac, and I think we should match
4.x and other-browser behaviour on Unix.

Please don't do this to us.

I believe I am a "typical" user.  Windows as well.  I am not a developer - I
merely use my browser for surfing.  Yet I don't understand the need for special
casing the address bar.  I find it frustrating when I want to merely change part
of the address to go to a related site and I have to unhighlight the selection
after a single click.  Merely give me the ability to double click to select and
I have everything I need.  Modifying the behaviour to save me a mouse click
sounds ludicrous.  How many clicks over the course of a browser session are you
really saving? Single click inserts caret.  Double click (or click and drag)
selects.  How much simpler could it be?
There are plenty of people (on all three platforms) who dislike the select-all
behavior.  There is absolutely no need to force this behavior on everybody,
especially on platforms where no other application has ever behaved this way. 
Removing configurability that we already have, which lots of users have asked
for, which follows standards for at least one platform, would be silly and
pointless.

The rest of Matthew's suggestions sound reasonable.
Hmm, this is on my plate now...yikes.

Since this is a UI design issue in xpapps land, I'd say it's either up to 
Matthew or I to make the final call.  Since I'm a Windows dork, I'd rather 
leave it up to him...Matthew, do you still still by your comment earlier today 
in light of the bloodshed that followed?

For what it's worth, shaver's opinion sounds like the most sensible to 
me...just match 4.x behavior for each platform.
i also strongly agree with shaver's 2001-04-12 08:56 comment, as well as
akkana's 2001-04-12 11:13 sentiments re: configurability.
Well of course you do -- you don't have to pay every couple of days to download 
the bloat expended in implementing this pref. Feh. ...Ahem.

This is not (as Akkana supposed) an issue of `no other application ha[ving] 
ever behaved this way' on Unix, because no other application ever behaved this 
way on Windows or Mac OS, either ... until Web browsers came along. As I said 
in my 2000-04-29 comment, the standard for *all* text fields, on *all* 
platforms, is for a click to place the caret rather than to select the contents 
of the field.

And indeed, this is how early versions of Mozilla (aka `the Netscape 
Navigator') worked. This suited users just fine, since the early adopters of 
the Web were technically-minded people, who spent a lot of time hacking at URLs 
in order to (a) get links which were slightly broken to work or (b) navigate 
URL hierarchies in the absence of clueful site navigation.

However, this quickly changed. The Web became very popular very fast, among 
non-technical as well as technical people. URLs started to be advertised 
outside of the Web, and as a result, users had to type them in (rather than 
follow hyperlinks from other pages) in order to visit them. So for the majority 
of users, click-to-select saved more time overall than click-to-edit. The sort 
of people who are CCed to this bug (Shaver, Akkana, Blake, me, et al.), the 
people who spend a lot of their time hacking off the number from a
"http://bugzilla.mozilla.org/show_bug.cgi?id=" URL in order to add a new 
number, or deleting trailing bits of hierarchy from an URL in an attempt to 
find a moved page, started to be in a minority which became (relatively) tinier 
and tinier.

So, Navigator for Windows switched from click-to-edit to click-to-select 
between Mozilla/1.1N and Mozilla/1.22. And Navigator for Mac OS switched from 
click-to-edit to click-to-select between Mozilla/2.0 and Mozilla/3.0. Were 
there vicious flamewars amongst the development team, about this particular 
text field not matching 1.1x or 2.x behavior, or starting to behave differently 
from any other text field on both of those platforms? Probably. I don't know, I 
wasn't there. But I bet they didn't have a `1xp' keyword in their bug database.

So why didn't Unix change as well? Mike Shaver's argument appears to be that 
Unix users are generally more computer-literate than those on other platforms, 
so they are much more likely to want to hack URLs in the address field (rather 
than just enter new URLs) than users of other platforms are. That's probably 
true, but I would suggest that (thanks to Linux) it will only be true for 
another couple of years at most. (I would love to know whether the people who 
can be regularly seen on Slashdot and elsewhere, expressing their wish that 
Internet Explorer -- which uses click-to-select -- would be ported to Linux, 
are (a) current Linux users or (b) current Windows users wanting to migrate.)

The other consideration, of course, is the traditional X11 select-to-copy 
behavior -- a hangover from the days when there were no Unix GUI apps which did 
formatting (e.g. word processors or spreadsheets), and there were powerful 
keyboard commands for deleting (^A, ^K, ^W), so the only reason to select text 
was in order to copy and paste it. But since we're not using the native
Motif/GTK/Qt text field, we don't need to copy the URL on click-to-select, just 
as not using native widgets allows us to avoid the minor bugs which have always 
been present in the Windows and Mac OS native text fields.

Absolutely this bug shouldn't be implemented, at all, until bug 62496 is 
resolved fixed. Whether it happens after that I'll leave up to Shaver, since 
he's @mozilla.org and I'm not so he could overrule what I decided in any case. 
But I predict that even if Unix goes it alone in click-to-edit, it will be 
forced by user pressure to change to click-to-select within a couple of years. 
Thus endeth rant.
Depends on: 62496
If we're really waiting for 62496 to be fixed, then pushing this off to .9.1 
(to which the bugs on that list are targetted).
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → mozilla0.9.1
Splitting up the tasks mpt listed (2001-04-12 08:23):

(1) and (2) are now covered by bug 78082.  
(3) is covered by bug 62495.
(5) is now covered by bug 78083.

So this bug is left with enabling browser.urlbar.clickSelectsAll by default 
(once most of bug 62496's dependencies are fixed), and then eventually (4) 
removing the pref.
*** Bug 8894 has been marked as a duplicate of this bug. ***
Renominating for nsbeta1 (from nsbeta1-) because bug 8894 was nsbeta1+, and 
copying rtm nomination from bug 8894.  Also adding mostfreq since this bug now 
has 10 direct dups.
Keywords: nsbeta1- → mostfreq, nsbeta1, rtm

*** This bug has been marked as a duplicate of 8894 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → DUPLICATE
Reopening to switch the duping back, since most of the discussion about the 
feature is in this bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 8894 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.1 → mozilla0.9.2
I am a Linux user and I would definitely prefer Mozilla to stick to click-to-edit.

Should Mozilla implement click-to-select just because it is a lex IE? Especially
in a case where IE violates standard behavior for text boxes? In my opinion
browsers should not be treated as special cases for UI. Also NY Times articles
should not be decision criteria, what if one of them complains about Mozilla not
matching IE non-standard rendering...

I am accustomed to current behavior and would appreciate at least a pref to be
able to keep it.
Vishy, marking this nsbeta1+ on behalf of nav triage.  The NY times article
wasn't the only source of feedback we got on this issue.  In addition to other
articles, and newsgroup postings, I've personally heard this complaint many
times from users within the company who I would consider close to the target
customer demographic.  I don't disagree that we should have some
platform-specific cases if really necessary (and sounds like from this bug that
that is the case), however we need to solve the 80% case, which from all the
data I have seen (90+% of our users are windows users and many complained about
this behavior) is that a single click should select the URL bar text, and the
second place the cursor in the text.
Keywords: nsbeta1 → nsbeta1+
Nav triage: can you please go through the dependencies of bug 62496 and see
which of those should also be targetted to mozilla0.9.2?  I don't think this bug
should be fixed until clickSelectsAll behaves more nicely than it does now.
Vishy, Paul, we need to update our queries to catch stuff like this (blake's
stuff anyway).
>But since we're not using the native Motif/GTK/Qt text field,
>we don't need to copy the URL on click-to-select [...]

Yes you do. That's the copy and paste interface that every x app uses. Any X app
that does not quickly gets annoying, once you're used to click-to-copy. Mozilla
needs to follow the standards for the platform it is running on. Having a
standard interface makes it much easier to use the program.

[Heck, even Windows programs on Windows boxes get me annoyed that I can't copy
and paste that way. It's easier. Especially since I have a 3-button mouse.]

Going against select-to-copy is as bad as deciding the Mac port will use
Command-C to cut (after all, cut starts with C, and we all use cut more often to
move text around, right?) and Command-X to copy (short for Xerox[R]).

anthony.derobertis@crossmedia.net: you'll still be able to select the URL
manually if you want to copy the URL to the transient X clipboard.  See bug
62495, "clickSelectsAll should not trigger if you're selecting text".
Is there no way on X to make click-in-url-bar-then-type overwrite, without
destroying the clipboard? Netscape 4 and Mozilla have always behaved somewhat
funky with X's clipboard, and often exibit very abnormal copy/pasting behavior.
I'd go in to examples but this doesn't seem to be the place.

If there is a way, personally, i'd prefer the IE-like behavior on my UNIX
systems. Sure I sometimes edit URLs, but for all users I'm sure new URLs are
more common then editing. So click-<end> to edit, is a lot easier then
click-drag, or click-<home>-<shift+end>, or click-click to edit.
This is really easy to fix. The only reason I haven't done so yet is because 
everyone's still fighting about what to do on each platform...
Status: REOPENED → ASSIGNED
Blake,  I think we should proceed by a) fixing this, b) adding a pref.  If we
can then set the pref differently on different platforms, let's do it.  If not,
I think Linux users are savvy enough to find the pref and switch it.  I saw more
instances of this suggestions (single click URL field selection) in the
newsgroup feedback for 6.1 PR1.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
*** Bug 87205 has been marked as a duplicate of this bug. ***
I much prefer standard edit field behavior. Having the URL field as a special
special case _is_ annoying to me. Maybe whoever first made it a special case
should have inverted the click-edit / double-click-select behavior so that quick
editing would still be available, but a pref would be even better. The best
place for the pref would, IMHO, be in the Preferences dialog.

Click-select then <end> key is not satisfactory because I've already reached for
the mouse and adding the additional reach for the <end> key is just as slow as
click-select->wait->click-edit (the IE behavior)

If the final say is that it should merely be platform-specific and not be
available in the Preferences dialog, maybe someone should sneak in an Easter
Egg to enable stadard edit field behavior (^;

Failing that, I'd rather download the source of every major release, set the
standard behavior myself, and compile than put up with click-select. From the
responses in this thread, I guess I'll have to get back into my programming
books (-;

IIsi 50MHz
Cincinnati, Ohio, USA
iisi50mhz@aol.com

    
    

    
  
Defaults to off for linux, on for everything else, I can't believe we have a 
pref for this...

I saw lots of pr1 feedback about this too, but that doesn't mean anything, 
because we don't know what the feedback will be once it's on.  Ideally we'd have 
released PR1 with click-selects-all behavior...
Whiteboard: fix in hand

    
    

    
  
iisi50mhz@aol.com: see mpt's 2001-04-23 07:32 comments in bug 62491.  This bug
is marked as depending on bug 62491, which may or may not mean that 62491 will
be fixed first.

Blake: does your patch fix any of the dependencies?

    
    

    
  
78082 would be easy enough to fix, but this doesn't fix it.  It fixes 78083.

    
    

    
  
Also fixes bug 62493, and basically makes bug 62495 a moot point.

    
  
Depends on: 87348

    
    

    
  
I'd like to see the changes in navigator.js to have a try/catch around them.
On blur, why do we remove the selection?  Wouldn't it be better to just let the 
selection lose focus?

In all.js, there should be a space after the ',' (before "true") to be more like 
other prefs in that file.

unix.js should also have a space after the ',' to be like the other prefs in 
there.


    
    

    
  
Removing the selection onblur is probably a workaround for bug 36848, "Should
only be one text selection per window".

    
    

    
  
If that were the case, we'd always do it; not just for this preference.
If we have to keep it, I'd prefer URLBarBlurHandler to check for gClickSelectsAll 
> 0 (or == 1).

I recommend removing it and testing it to confirm it's not necessary.  :-)


    
    

    
  
I did try removing that.  Then what happens is that the next time you click in 
the url bar after it's already blurred once, you end up not selecting all the 
text, because it's remembering the previous selection (so the click is 
cancelling the previous selection).

What needs a try/catch, and why?

Theoretically (and by definition), the textbox can't be blurred unless it 
already took focus.

    
    

    
  
with the addition of the try/catch, r=brade

Please file a bug on the issue of the selection needing to be removed; then your 
comment could point to that bug.  :-)


    
    

    
  
<summary of an email I sent to blake>
This bug fixes both the clicking and tabbing to URL bar selection problem. I 
suggest a change in the name of the pref to |focusSelectsAll| and a likewise 
change to the variable ->gFocusSelectcAll. I will post a diff that makes these 
changes and removes the fix for bug 83588 which only fixes the tabbing case.
</summary>
Keywords: access

    
    

    
  
Oops, I thought you just wanted to change the variable name, not the pref.  I 
don't think we should change the pref because of users who are using old 
profiles and already have the old one.  I don't think the benefit outweighs the 
cost.

    
    

    
  
Hmm... then keep the variable name the same. No sense confusing things. But 
definitely take out the code for the keyup stuff I did. You can see it in my 
diff -- navigator.xul navigator.js -- the function and the handler registration.

    
  
Keywords: nsBranch
Whiteboard: fix in hand → fix in hand, needed for accessibility

    
  
Keywords: vtrunk

    
    

    
  
blake, i'd like to just land this as part of the accessibility landing on the
0.9.2 branch today. Does that work for you?
Whiteboard: fix in hand, needed for accessibility → fix in hand, needed for accessibility, PDT+

    
    

    
  
It wouldn't make sense to rename clickSelectsAll to focusSelectsAll, because the
pref should only affect clicking.  Tabbing to a text field should always select
the contents of that text field (bug 28583).

    
    

    
  
What is the "accessibility landing on the 0.9.2 branch"? Are we actually taking
"landings" on the branch at this late date - or did you just mean a set of
targeted bugfixes? Does this bug need to be PDT+?

    
    

    
  
verified using the following comm trunk builds:

linux 2001.07.05.08: tabbing to URLbar inserts cursor at the end of the field
contents; single-clicking places the cursor where the mouse pointer is located.
[both expected by default on unix.]

winnt 2001.07.05.09: tabbing to and single-clicking in the URLbar
selects/highlights its entire contents.

mac 2001.07.05.08: tabbing to and single-clicking in the URLbar
selects/highlights its entire contents.

removing vtrunk kw.

yes, this ought to be checked into the branch.
Keywords: vtrunk

    
    

    
  
Can something be done to get this to work on UNIX, without trashing the
clipboard? I and I'm sure many other UNIX users would prefer click selects all.

If the clipboard needs to be trashed for 1.0, I'd still like a pref to turn this
on, I think the benefits would outweigh the disadvantage.

Could a workaround be just not highlighting the text, but <click>-<type> would
have the effect of overwriting what was there anyway (under UNIX only). This
would have to be off by default since it's non-obvious, but would be a nice
tunable feature for power users. <click>-<arrows/home/end/backspace> would skip
this special case clearing.

(Sorry, just trying to dump my brain before this bug gets buried, leaving for
vacation in a few hours)

    
    

    
  
Have you tried this? As far as I know a mechanical content selection (e.g.
through javascript, as is done here) does not overwrite the clipboard at all.
Only user drag select or double-click select does.

    
    

    
  
vishy/all, accessiblity landing on the branch is for a key embedding customer that
will also use the branch for shipping.

is this fix ready to go on the branch?

    
    

    
  
Yes, this fix is all ready. John, are you going to land it?

    
    

    
  
This was checked into the branch wed 4 july.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Whiteboard: fix in hand, needed for accessibility, PDT+

    
    

    
  
Is there a pref to set so this works on UNIX?

    
    

    
  
user_pref("browser.urlbar.clickSelectsAll", true);

    
    

    
  
verified fixed on the branch using the following comm branch builds:

linux 2001.07.09.04: single-clicking places the cursor where the mouse pointer
is located. [expected by default on unix.]

winnt 2001.07.09.05: single-clicking in the URLbar selects/highlights its entire
contents.

mac 2001.07.09.03: single-clicking in the URLbar selects/highlights its entire
contents.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite

    
  
Component: XP Apps: GUI Features → UI Design

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: