Michael Wardle Reporter
	Description • 23 years ago

Most user interface standards I'm aware of specify that:
- single click positions the text insertion point ("I bar" or "caret")
- double click selects the word under the cursor
- triple click selects the line under the cursor (or sometimes the paragraph?)

Therefore I propose that Mozilla follows these guidelines in the URL bar.  It
already does this in the text editing fields, so should do so in the URL bar for
consistency.

Other applications that do this that come to mind are Galeon and Microsoft Word.

	timeless
	Comment 1 • 23 years ago

.

	Michael Lefevre
	Comment 2 • 23 years ago

not quite the same as specified, but this is pretty much a dupe of bug 62491 ,
isn't it?

	Michael Wardle Reporter
	Comment 3 • 23 years ago

The discussion in that bug does, in a vague way, relate to this bug, I guess,
altho that bug's summary is almost the opposite (mutually exclusive) with what
I'm saying.  I worry that if this gets duped, the issue won't be discussed or
resolved, as the other one's already closed.

	Jesse Ruderman
	Comment 4 • 23 years ago

Triple-clicking should select a word, not double-clicking 
(http://bugzilla.mozilla.org/show_bug.cgi?id=62491#c10).  Using double-clicks 
to select a word within the URL bar would make it harder to place the insertion 
point without selecting anything.  Wontfix.

	Mikel Ward
	Comment 5 • 23 years ago

I did not see any clear agreement in bug 62491, and it's still not resolved.

The behaviour suggested in bug 62491 is inconsistent with other text fields, and
so I strongly oppose it.

	Mikel Ward
	Comment 6 • 23 years ago

Bug 62491 comment 2 agrees with me.

Indeed, about the only consensus in that bug is that what you want, Jesse, is
only relevant if "clickSelectsAll" is enabled (according to that bug's summary).

I'm talking about standard GUI behaviour.

	Michael Wardle Reporter
	Comment 7 • 23 years ago

I don't like the way you WONTFIXed this bug, especially as you have an agenda
going in bug 62491, even tho I do not believe you had consensus there, either.

Is WONTFIXing a valid and fair way of getting what you want?

	Michael Wardle Reporter
	Comment 8 • 23 years ago

To elaborate, this bug should be used to get consistent, standard text field
behavior (as per bug 62491, comment 10) to also apply to the URL bar.

I expect this is applicable when clickSelectsAll is *not enabled* (standard Unix
behaviour, I believe).

	Jesse Ruderman
	Comment 9 • 23 years ago

Sorry for the hasty wontfix, I didn't realize you were talking about the case
where clickSelectsAll is not enabled.  (To prevent this kind of
misunderstanding, I often use the "steps to reproduce, expected behavior, actual
behavior" pattern when I file bugs instead of just stating what I expect to happen.)

I think this is a duplicate of bug 98546, "Better word-break detection
(double-clicking, Control+arrow keys, Control+Backspace/Delete)".  The problem
isn't that Mozilla is doing the wrong thing with double-click, it's that it's
considering the entire URL to be a single word instead of considering slashes to
be word breaks.

	Akkana Peck
	Comment 10 • 23 years ago

This is essentially a dup -- but that bug has gotten so crowded with issues that
I don't think Mike is even looking at it.  I think it's helpful to have another
bug open that clearly states the simple problem, which is that double-click
often doesn't do word selection in the url bar as it should.  It's basic
functionality that every other app does right, and it really should be fixed. 
Reassigning to Mike (but keeping hewitt on the cc in case there's some reason he
didn't reassign it earlier).

	mjudge
	Comment 11 • 23 years ago

this is the same bug that i just bounced to pink. pink you could DUPE this to 
the onei just sent you as well as see if we can fix this for windows like on 
mac?

	Mike Pinkerton (not reading bugmail)
	Comment 12 • 23 years ago

i'm very confused. mjudge bounced me one bug which had nothing to do with the
fact that the url bar uses different click semantics than any other textbox in
existance.

this bug, by the summary, is about that aspect. --> default owner

	Michael Wardle Reporter
	Comment 13 • 23 years ago

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

	Michael Wardle Reporter
	Comment 14 • 23 years ago

Don't know what happened there...

Reopening, removing duplicate...

	Dean Tessman
	Comment 15 • 22 years ago

I just commented in bug 98546, but maybe that comment belongs here instead...

IE (Windows) handles double-click two different ways.  If you enter
"http://bugzilla.mozilla.org/" in the Address field, keep that field focused,
and double-click "mozilla", the entire address is selected.  If you repeat the
same action in a text field, only "mozilla" is selected.

	Aaron Leventhal Assignee
	Comment 16 • 22 years ago

My fix for this is part of the patch in bug 98546.

	Aaron Leventhal Assignee
	Comment 17 • 22 years ago

fixed via checkin for bug 98546.

	James Graham
	Comment 18 • 22 years ago

The behaviour I expect is described in bug 62491, specifically bug 62491 comment
10. Note that this makes a special case of the URL bar. Several people have seen
the new bevaiour as a regression (see, for example, bug 188567). It it notable
that IE makes a special case of the URL bar (using the select all - place caret
- select word approach), which makes more sense if click to select is enabled
since the second click is the first time the caret appears and the third click
then selects the word containing the caret. This behaviour is consistent with
other applications (first click places caret, second click selects word), but
with an extra click at the start because a common URL bar operation is replacing
the whole URL with that for a different site. The current bevaviour is for the
rather odd select all - select word - select all.

Therefore at the very least, the patch for this should be dependent on the
clickToSelect pref.