8894 - First click to focus url bar should select url

Status: VERIFIED DUPLICATE of bug 37587

(SeaMonkey :: Location Bar, defect, P3)

Description

[cpratt]

Build ID: 1999062414 (Mac OS), 1999062508 (Linux, Win32)

To reproduce:
- Launch apprunner
- Load Yahoo!
- Click into the text input control in the body of the document
- Click once into the Location: control

Result:
- Mac: Blinking insertion cursor positioned at far left regardless of where you
clicked with the mouse
- Linux and Win32: Insertion cursor position at location of mouse click

Expected result:
- All platforms: The entire URL should be selected if we are to do the same thing
as legacy browsers.

Now, double-click in the Location: control.

Result:
- Mac: Text between "http://" and "/" is selected.
- Linux: The individual 'word'  is selected. That is, if you double-click on
'yahoo', yahoo is selected.
- Win32: The entire contents of the Location: control are selected.

Expected result:
I'm not sure what the expected result should be as the legacy browsers behave
differently on different platforms. I would expect we'd need guidance from the UI
folks on this one.

Comment 1

[Kathleen :Brade]

There are really 2 different bugs here.  The first one listed above is platform
specific and will presumably go away with gfx widgets.  If not, please file a
separate bug.  The second bug is specific to browser location widget.  I think
Radha was working on this so I'm reassigning to her; radha please reassign if
appropriate.

Change component to browser; cc [e-mail].

Shuang--who is responsible for the appropriate behaviors of this widget (so radha
or whoever ends up with this bug will know who to consult)?

Comment 2

[don]

Move this to M11 ...

Comment 3

[shuang (gone)]

german is responsible for the design of new behavior. cc german. I think radha
already is talking to german. If not, please do so...

Comment 4

[Radha on family leave (not reading bugmail)]

Reassigning to buster to make sure this istaken care in gfx widgets

Comment 5

[buster]

rahda, I don't know why you assigned this bug to me.  Which part of it do you
expect me to do?  My job is to enable gfx text controls with default behavior,
plus all the standard notifications so default behaviors can be overridden.  If
the URL bar needs some non-standard behavior, it should handle clicks and double
clicks and so forth itself.  If gfx text controls aren't sending out the
appropriate notifications to make this possible, I'll implement those.

German, since behavior is currently different per platform, we need some
guidance here about what ought to happen.

Please advise.

Comment 6

[buster]

added radha to cc list.  radha:  please see previous comment.

Comment 7

[german]

I agree with Christopher: when the URL control first receives focus after the
focus having been on the page it should select the whole URL.
We should also select the entrire URL on double click inside the URL fields
unless there are major objections on Linux that I might be aware of. Requiring
triple click on the Mac for the common usage of selecting the entire URL is too
much of a hassle for end users (especially when we have long winding URLs that
users are trying to get rid of in the URl field). Selecting the entire URL
should be made as accessible as possible even if it means going against some of
the platform legacy for text edit fields. Re-assigning back to Radha to check
who could implement this behavior.

Comment 8

[cpratt]

Note that this is (presumably) all different now due to gfx now being enabled.
Using the 19990914xx builds on Linux and Windows NT gives the same result: when
you click in the Location: control, the caret is not drawn where you click, but
ALWAYS at the end of the text in the Location: text input control.

Comment 9

[Radha on family leave (not reading bugmail)]

Not a dogfood requirement

Comment 10

[don]

Move to M20 target milestone.

Comment 11

[Matthew T (active 1999-2002)]

This bug seems to be tracking four issues, two of which are covered elsewhere:
* selecting the entire contents of the location bar when clicking in it -- bug
  37585, VERIFIED INVALID;
* selecting the whole of a text field when it is given focus using the keyboard
  -- bug 28583, MFuture helpwanted.

The two remaining issues here are:
* placing the caret as close to {under the cursor} as possible, when the location
  field is clicked in;
* special-casing the location field so that a double-click selects an entire URL,
  rather than just selecting the target OS's normal definition of a `word'.

Eli no longer with us, QA --> Claudius.

Comment 12

[Asa Dotzler [:asa]]

the invalid singleclick in URL field selects URL bug is bug 37587 for anyone 
looking.

Comment 13

[sairuh (rarely reading bugmail)]

akkana/anthonyd, d'you think this would be dependent on bug 16352 and/or bug
47469?

Comment 14

[Akkana Peck]

I don't see a dependency, but then, I'm not sure what this bug is currently
tracking.  Is the caret still being set to the wrong place on the mac?  That
report was ancient, pre gfx text widgets, and I'm not clear whether it's still
happening.  Cpratt's report of the caret being set to the end was probably a
transient effect when gfx widgets were switched on; at least, it's been working
for me for many months.  Asa pointed out that the click-selects-all is already
covered in bug 37587.  The two bugs se mentioned cover the bugs/inconsistencies
with double-click word selection.  What's left here?

Comment 15

[Radha on family leave (not reading bugmail)]

Mass moving all Navigator bugs to the Nav team. 

Comment 16

[german]

current behavior
1 click: insert caret at click poistion, 2nd or double click select whole
content of url widget seems to work pretty well for the majority of users. If
people are Ok with this we should close this bug.

Comment 17

[sairuh (rarely reading bugmail)]

i agree about the single and double click behaviors, but i don't feel that
click-pause-click should select the field's content.

Comment 18

[german]

sairuh: many beginners expect this to happen, they click once, pause then click
again, and they always want to wipe out the current content. Can you be more
specific as to why you think a second click selecting all poses a penalty?

Comment 19

[Akkana Peck]

German: are you talking about a very brief pause, i.e. shorter than the
double-click interval?  If so, I agree with you.  But if you're saying that any
time the text field has focus, a click in it should select-all or select-word,
but if focus is somewhere else then single click should set the caret, then I
definitely disagree.  It would be confusing to have to note where the focus was
before you could know whether a single click is going to set the caret or make a
selection.  This is the way other text fields work, on both Unix and Windows. 
If the default doubleclick interval is too short for beginning users, maybe we
need to address that problem and change the default (though I would think they
would see the problem in other apps as well).

Comment 20

[Chris McAfee]

alecf.  Isn't there a pref for this? ...

Comment 21

[Akkana Peck]

"browser.urlbar.clickSelectsAll"

Comment 22

[Jesse Ruderman]

I think clickSelectsAll should eventually be enabled by default, and so a 
second click (whether fast or slow) will de-select the text and place the 
insertion point.

Bug 62493 might also create the problem Akkana is talking about, where a single 
click would have a different effect depending on where focus is, but I think 
that if you're already editing the URL and click in the location bar again, 
you're more likely to want to continue editing it than to want to replace it.

Comment 23

[Viswanath Ramachandran]

nominating for nsbeta1. 

Comment 24

[Jesse Ruderman]

Dup of bug 37587, which is now mostfreq.  Since this bug is nsbeta1+ and that 
bug is nsbeta1-, I'm going to renominate 37587 for nsbeta1.  I'll also copy the 
rtm keyword over.

*** This bug has been marked as a duplicate of 37587 ***

Comment 25

[cpratt]

This is not a duplicate of bug 37587. Bug 37587 was filed ten months later than 
this one was.

Comment 26

[cpratt]

Changing keywords.

Comment 27

[David Avery]

I sincerely hope that this is NOT changed for *ix builds as click sets caret is
the accepted style on *ix 

Comment 28

[Jesse Ruderman]

I marked this as a dup of 37587 and not vice-versa because 37587 had more 
comments, more recent comments, more votes, nine dups, and a list of 
dependencies.  Bug number is a factor in deciding which way to dup, but it's 
not the only factor.

*** This bug has been marked as a duplicate of 37587 ***

Comment 29

[cpratt]

I don't know who you are, davidr8, but as a Netscape employee, let me just say 
this (once again): my yearly salary review is based in part on how many valid 
bugs I file. It has a direct negative impact on my pay rate whenever someone 
marks one of my bugs a duplicate of another bug *filed nearly a year later*. 
That's all I have to say on the subject - I'll shut up now.

Marking VERIFIED DUPLICATE.

Comment 30

[Matthew T (active 1999-2002)]

Christopher: Jesse Ruderman (davidr8) is probably the best QA volunteer 
currently working on the Mozilla project. By your own definition of `valid 
bugs', he has filed 3/4 as many valid bugs as you have, for no salary 
whatsoever, and on top of that he has done just as much (if not more) helpful 
work again in cross-referencing related bugs with each other.

Earlier bugs in Bugzilla are often marked as duplicate of later bugs, for the 
reasons Jesse gave (though the fact that this bug report was filed about at 
least two distinct problems can't have helped either). If this is causing your 
employers to have an inaccurate perception of your own QA performance, I 
suggest you ask Asa to talk to them about it -- and/or to create a 
`nsNotMyFault' keyword. :-)

Comment 31

[Alec Flett]

cpratt: don't muck up bugzilla with your own personal issues. Being a Netscape
Employee does not give you more bugzilla clout than any other Mozilla contributor.

If you have a problem with your bugs being marked dupe (most QA people don't
seem to) then save a list of bugs like this and give it to your manager. It's
not a mozilla issue.