Last Comment Bug 190615 - make stop_at_punctuation=true the default on unix (double-clicking shouldn't select punctuation)
: make stop_at_punctuation=true the default on unix (double-clicking shouldn't ...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Selection (show other bugs)
: Trunk
: x86 Linux
-- enhancement with 17 votes (vote)
: mozilla1.9alpha8
Assigned To: Dão Gottwald [:dao]
:
: Jet Villegas (:jet)
Mentors:
http://bonsai.mozilla.org/cvsblame.cg...
: 176354 245708 249656 257922 302277 313723 315112 334630 348787 354721 354858 360601 362467 369629 374394 378988 381972 389516 404356 410475 (view as bug list)
Depends on: 193025 366797 393828
Blocks: 611162
  Show dependency treegraph
 
Reported: 2003-01-25 11:24 PST by Max Gilead
Modified: 2012-11-09 15:21 PST (History)
63 users (show)
dbaron: blocking1.9-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch to remove the overriding of the default stop_at_punctuation=true on Unix/Linux (681 bytes, patch)
2004-01-06 22:54 PST, Robert Parenton
akkzilla: review-
Details | Diff | Splinter Review
(again) Patch to remove the overriding of the default stop_at_punctuation=true on Unix/Linux (681 bytes, patch)
2006-09-29 05:54 PDT, Alan Siu-Lung Tam
no flags Details | Diff | Splinter Review
patch v1 (3.76 KB, patch)
2007-06-27 18:46 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
simplified patch, updated to current trunk (3.25 KB, patch)
2007-07-13 04:38 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch v2 (9.66 KB, patch)
2007-07-16 16:20 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch v2.1 (9.70 KB, patch)
2007-07-16 16:46 PDT, Dão Gottwald [:dao]
asaf: review-
Details | Diff | Splinter Review
patch v3 (9.65 KB, patch)
2007-07-22 16:15 PDT, Dão Gottwald [:dao]
asaf: review+
Details | Diff | Splinter Review

Description User image Max Gilead 2003-01-25 11:24:13 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030125
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030125

Too much text is selected in source preview window when clicked on a word in
parentheses.

Eg.:
clicking on 'func' in  class="func"  selects entire phrase instead of just 'func'
clicking on '0000ff' in color="#0000ff" selects entire phrase instead of just
'0000ff' or '#0000ff'

Reproducible: Always

Steps to Reproduce:
1. Open page preview window or any page with text in parentheses
2. Click on text in parentheses

Actual Results:  
Entire phrase is selected.

Expected Results:  
Only text in parentheses should be selected.
Comment 1 User image Josh Birnbaum 2003-01-25 13:00:44 PST
->selection
Comment 2 User image Max Gilead 2003-01-26 14:38:49 PST
Similarly, double-clicking on 'max_size' in  (int max_size); selects
'max_size);' instead of just 'max_size' so it's problem not only with parentheses.
Comment 3 User image Vaclav Dvorak 2003-03-01 16:53:19 PST
Unless I'm mistaken, this is working as designed. There is a hidden pref called
"layout.word_select.stop_at_punctuation" that is false by default (only?) on
Unix, allegedly in order to be consistent with normal Unix behaviour. If you
want word selection to stop at punctuation, set the pref to true. However, there
is also bug 193025 about this not working when you set that pref in your user
profile's prefs.js, so you currently need to change the default in <moz inst
dir>/defaults/pref/unix.js.

Resolving INVALID.
Comment 4 User image Max Gilead 2003-03-02 03:10:54 PST
I'm sorry but being an Unix user I can't see such behavior anywhere. Just
verified it in bash, xedit, gedit, joe and vim - all of them behave exactly as I
suggested Mozilla should. So I disagree that this bug report is invalid.

I believe the preference you specified should be changed for Unix.

Adding ability to edit this in preferences window could accompany this change
but I personally don't think it's necessary.

Regards,
Max
Comment 5 User image Vaclav Dvorak 2003-03-02 14:40:34 PST
See bug 98546 comment 18 and bug 98546 comment 104. You'd have to get some
positive feedback from other unix users to persuade Akkana. You have mine, but
I'm not a "native" Unix user. ;-)

Clarifying summary (was: Double-clicking on a word in parentheses selects too
much text), and confirming.
Comment 6 User image Robert Parenton 2004-01-06 22:54:52 PST
Created attachment 138526 [details] [diff] [review]
Patch to remove the overriding of the default stop_at_punctuation=true on Unix/Linux

This should do the trick.  However, as Vaclav Dvorak stated in comment #5,
persuading Akkana that this is the normal behavior on Unix/Linux is the key to
getting this checked in.
Comment 7 User image Vaclav Dvorak 2004-01-07 15:25:17 PST
Comment on attachment 138526 [details] [diff] [review]
Patch to remove the overriding of the default stop_at_punctuation=true on Unix/Linux

How about trying it in 1.7a and revert it back if too many Unix users start
complaining?
Comment 8 User image Akkana Peck 2004-01-07 21:05:08 PST
Comment on attachment 138526 [details] [diff] [review]
Patch to remove the overriding of the default stop_at_punctuation=true on Unix/Linux

A straw poll on #mozilla (very small sample size) had about 70% of users being
against it (with varying degrees of vehemence) and the rest being neutral;
nobody was strongly for it.

I still stand by that bug 98546 comment 104: if you post to mozilla-unix and a
significant number of people speak up and say they want it, and/or (preferably
and) you special-case the urlbar (which probably means overriding a click
handler in browser.js or somewhere like that), I'll check it in.  A couple of
people saying they want it isn't enough to change urlbar functionality to
require three clicks instead of two.
Comment 9 User image Malcolm Smith 2004-02-20 07:06:37 PST
I don't understand bug 98546 comment 18 ("Unix browsers typically don't stop at
punctuation (makes life difficult in the urlbar)") - when changing from Galeon
1.3 to Firefox 0.8 I found this a significant regression.

Editing actions done in the URL bar are different to actions carried out in
normal textboxes. Specifically, the url bar never contains spaces, so breaking
only on spaces while processing the ctrl-left/right keys is useless. Instead,
ctrl-left/right should stop at the common url delimiter characters (bug 98546
comment 30), allowing swift editing of the URL with the keyboard rather than
fiddly pinpointing of the mouse or character-at-a-time positioning with
left/right keys.

Life would be much easier in the url bar if this was the case.

I'm talking here only about the ctrl-left/right word-at-a-time navigation keys.
What gets selected on a double-click seems to me to be a separate and less
important issue.

Furthermore, apparently due to Bug 193025, I can't easily check to see if
changing the hidden pref makes life more comfortable.
Comment 10 User image Malcolm Smith 2004-02-20 07:11:35 PST
(In reply to comment #9)

> Furthermore, apparently due to Bug 193025, I can't easily check to see if
> changing the hidden pref makes life more comfortable.

In Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 ,
changing the pref to true with the about:config interface causes the left/right
keys, ctrl or not, to not move the caret at ALL in the url bar.

Comment 11 User image Jerry Quinn 2004-04-26 13:42:02 PDT
Setting layout.word_select.stop_at_punctuation to true makes the URL bar behave
reasonably.  *PLEASE* make this the default on Unix, or at least Linux.  Having
it set false makes editing URLS nearly impossible.  What purpose does that
setting serve?

With it set true, double clicking still grabs the whole URL, so that ability
isn't lost.
Comment 12 User image Akkana Peck 2004-04-26 14:20:54 PDT
> With it set true, double clicking still grabs the whole URL, so that ability
> isn't lost.

For me, when I set that pref, doubleclicking in the urlbar stops at punctuation.
(I tried it with my normal profile in 1.7 RC 1, and with my debug build, mostly
default, in a current tree.) I wonder what's different about our setups?  Can
you try it with a new profile, see if it's different, and maybe track down the
difference?  If we could solve the urlbar doubleclick problem, I'd be much less
worried about making this change.  Any comments from other testers?
Comment 13 User image Jerry Quinn 2004-04-26 14:36:08 PDT
(In reply to comment #12)
> > With it set true, double clicking still grabs the whole URL, so that ability
> > isn't lost.
> 
> For me, when I set that pref, doubleclicking in the urlbar stops at punctuation.

Sorry about that.  I mean triple-clicking.  I wasn't trying to say it's broken.
 Rather, that it's still possible to select the whole url with the pref set to
true.  Trying to convince the powers that be to change this :-)
Comment 14 User image Jo Hermans 2004-07-03 02:58:05 PDT
*** Bug 249656 has been marked as a duplicate of this bug. ***
Comment 15 User image Jerry Quinn 2004-07-07 20:15:07 PDT
What's the current status on this bug?  Any chance of getting in before firefox 1.0?
Comment 16 User image Neil Paris 2005-02-18 18:43:32 PST
*** Bug 245708 has been marked as a duplicate of this bug. ***
Comment 17 User image Jerry Quinn 2005-07-06 07:00:09 PDT
It's a year later.  Any thoughts on this?
Comment 18 User image Craig Turner 2005-07-28 18:51:11 PDT
Can we please see some action on this? After discovering the workaround to this
problem (which has niggled me for well over five years on mozilla and earlier
incarnations of netscape), I sent out a notes to other software developers I
know who are based on linux and have had several responses back of the form
"Man, that has been bothering me for ages as well. Thanks heaps for that little
gem."

The justification given for the current functionality is that it should be
"consistent with normal Unix behaviour". I'd be surprised to learn if there was
any consistent standard for anything to do with graphic user interfaces between
unix environments. Further, my experience is that this is incorrect anyway.
Certainly my builds of gnome-terminal and xterm don't work like this. It's
certainly very un-unix-like to cripple keyboard functionality so that you have
to use the mouse for something.

Further, regardless of what the truth of this situation is or isn't, I'd suggest
that it's up to projects with huge userbases like mozilla to set the pace
through good design rather than to reimplement poor functionality just because
that's how other programs have done it in the past. 

The current default is poor for people with keyboard-centric usage. People who
want to edit their URL bar without using the mouse currently have the following
experience:
(1) Press ctrl+L
-> URL bar highlights
(2) Press right
-> caret moves to end of the line
(3) Hold down backspace or shift+arrow for several seconds to highlight the bit
you want to highlight and then hope you let go at the right time.

When you tweak layout.word_select.stop_at_punctuation or use firefox in its
default configuration on mac or Windows, the behaviour is like this:
(1) Press ctrl+L
-> URL bar highlights
(2) Press right
-> caret moves to end of the line
(3) Press shift+ctrl+left to highlight the words you want to change
-> this is much quicker and more precise.

If you try this second process under the linux build of firefox, it highlights
back to the start of the line - an effect that can already be achieved with
ctrl+shift+home (or with the initial ctrl+l to highlight the location bar).

This is an annoying obstacle for users who use firefox to browse API docs all
day every day. They know what the class names are and want to be able to adjust
a path ending with /java/util/List.html to /java/lang/regex/Pattern.html, and
they don't want to have to lean on arrow keys every time they want to do it, or
reach across for the mouse and then play with the URL using that imprecise pointer.

The current default configuration is deficient. There are many users out there
who are annoyed by this and aren't aware that it can be fixed through
configuration. This in turn gives unix-on-the desktop a bad name because firefox
for Windows is perceived to be a better product than firefox for unix.

It may be that there needs to be a separate configuration set up for the URL bar
than from the rest of the application. My personal preference is for mouse
clicks to highlight words - you can always hold down the second click and then
drag the mosue to finish off the highlight and I've gotten used to that through
use of firefox on other platforms. Also, this situation could be improved by
deciding that this issue is controversial and adding checkboxes for it in the
configuration screens. But any way you look at it, this situation with the URL
should be fixed, and the default would ideally by consistent with firefox on
other platforms.
Comment 19 User image Uri Bernstein (Google) 2005-08-21 11:11:10 PDT
*** Bug 302277 has been marked as a duplicate of this bug. ***
Comment 20 User image Elmar Ludwig 2005-10-26 01:45:04 PDT
*** Bug 313723 has been marked as a duplicate of this bug. ***
Comment 21 User image Jens Bannmann 2005-11-01 01:43:40 PST
*** Bug 176354 has been marked as a duplicate of this bug. ***
Comment 22 User image Elmar Ludwig 2005-11-04 23:45:27 PST
*** Bug 315112 has been marked as a duplicate of this bug. ***
Comment 23 User image Reed Loden [:reed] (use needinfo?) 2005-11-17 19:42:16 PST
*** Bug 257922 has been marked as a duplicate of this bug. ***
Comment 24 User image Elmar Ludwig 2006-04-19 06:22:17 PDT
*** Bug 334630 has been marked as a duplicate of this bug. ***
Comment 25 User image Uri Bernstein (Google) 2006-09-29 03:56:21 PDT
*** Bug 354721 has been marked as a duplicate of this bug. ***
Comment 26 User image Alan Siu-Lung Tam 2006-09-29 05:54:22 PDT
Created attachment 240604 [details] [diff] [review]
(again) Patch to remove the overriding of the default stop_at_punctuation=true on Unix/Linux

Contrary to what comment #3 says, a lot of people do not think this as sane behavior, specifically comment #4, comment #7, comment #11 and the bulk of dupes. Comment #18 even states valid use cases demonstrating the meaningfulness for fixing this bug.

As a conclusion, unix users (at least the current generation) thinks that the current (deliberately chosen) behavior in unix is insane. I am now submitting the same patch for review again.
Comment 27 User image Uri Bernstein (Google) 2006-09-29 11:30:14 PDT
*** Bug 354858 has been marked as a duplicate of this bug. ***
Comment 28 User image simon.hetzer 2006-10-07 19:15:11 PDT
Instead of changing the default behaviour - which is as expected by traditional *nix users - a better approach might be to make the hidden preference more accessible and to raise awareness that this behaviour of Firefox can be changed.
This might also have a better chance of getting integrated, avoiding the discussion about the proper default.
The complaints are probably all from recent Windows converts.

For the record, I'm against having s_a_p default to true.
Comment 29 User image Anders Conbere 2006-10-07 23:04:03 PDT
from  #28 "The complaints are probably all from recent Windows converts."

I think it's presumptious to assume that:

a) the people requesting this change for linux builds are recent windows converts.  In fact I can only imagine that this comment was made to do two things.  First was to diminish the agency of those who are actually recent windows converts and view this as a reasonable request.  And second to create a false hierarchy, those who have been using *nix for x amount of time, and those who haven't and the presumption that anyone greater than X has more say, and thus a bigger vote.

b) that long time *nix users don't also consider this a reasonable request. (speaking from the point of view of someone who has been using the *nixes for quite some time an can say that certainly it's not only recent windows converts).  Infact clearly the developers of such popular desktop environments as GTK and QT have decided on one, and the fact that firefox doesn't conform to the standards of these desktop environments is not only inconsistent, but to most people who use these systems it seems broken.

--
Thus far the developers have done a good job of moving more and more to closer consistency with the desktop top environment being used, this has been a stated goal of at the very least the widgeting system and the theme.  The developers seem quite aware that consistency on a desktop are one of the more important usability rules, and I would hope that they can recognize that simply by try it out on a few applications native to those environments this behaviour isn't consistent.

Simply because Unix used to do it one way, the current environment does it another, and while I understand that there needs to be some stability to prevent a project from flipping back and forth and changing in the wind.  I don't see this changing any time soon.
Comment 30 User image Jens Bannmann 2006-10-07 23:34:15 PDT
(In reply to comment #28)
> Instead of changing the default behaviour - which is as expected by traditional
> *nix users - a better approach might be to make the hidden preference more
> accessible and to raise awareness that this behaviour of Firefox can be
> changed.

I don't think so. Firefox's core UI philosophy was always that it should work as-is and not offer thousands of options in its preferences dialog. If we started to offer UI for prefs like this, the end result will look like SeaMonkey's prefs dialog, and that would be a step backwards (no offense meant). I think we can all agree that Firefox's simplicity is one of the main reasons for its success among non-geek users, and we should preserve it. (I do realize this is a core bug and not a Firefox bug, but I think even for SeaMonkey this pref is too fine-grained to be added to the UI.)

> The complaints are probably all from recent Windows converts.

While I _am_ a "Windows convert", I do not see why this fact makes my opinion any less important. Besides, in contrast to what you imply here, the suggested behaviour (stop at punctuation) is not standard behaviour among Windows applications - I've encountered several applications that have it wrong.

For the record, I'm in favor of changing the pref to true.
Comment 31 User image Flávio Etrusco 2006-10-08 20:16:20 PDT
I thought one the biggest "selling-points" of a multi-platform browser was user interface consistency (a safe harbor to the user) across the different OSes and/or graphical systems?
GTK2 default (in Ubuntu at least) is to stop in punctuation for either double-click or ctrl+arrow. KDE/Qt default is to stop for ctrl+arrows but not for double-clicks. In Firefox both behaviors are controlled by a single preference, so I'd say the 'stop_at_punctuation=true' is the only option? Or is Firefox meant to mimic arena or motif and look like 20-year-old software?

BTW, "traditional *nix users" should be using Lynx instead! :-P

(I apologize for repeating the same old points again, but the fact that this issue is still unfixed shows that people either didn't like the way we've put it or that they didn't read the arguments at all...)
Comment 32 User image Craig Turner 2006-10-09 02:03:27 PDT
> Instead of changing the default behaviour - which is as expected by
> traditional *nix users.. [...] The complaints are probably all from
> recent Windows converts.

I've been using unix seriously for ten years, full-time on the desktop for five. I remember being specifically annoyed by broken behaviour for ctrl+arrow keys in the URL bar when I first started using Netscape Navigator on Linux at home in the mid-nineties and this lack of functionality continued to regularly frustrate me until I discovered the hack to change stop_at_punctuation in mid 2005.

The idea that this is a change needed for new people is incorrect. The current default behaviour has always been deficient for usage which prefers the keyboard over the mouse. I presented a use case to demonstrate this in an earlier post.

The default configuration of firefox should support word jumping in the URL bar via use of ctrl+arrow keys.

I believe Mac used to have stop_at_punctuation=false style navigation. I remember struggling with the near-broken mouses on OS 7 or 8 terminals at uni running Navigator 3. But a recent build of firefox for Mac on my laptop supports word jumping in the URL-bar via alt+arrow.
Comment 33 User image Jerry Quinn 2006-10-10 06:27:55 PDT
(In reply to comment #28)
> Instead of changing the default behaviour - which is as expected by traditional
> *nix users 

No, this is incorrect.  I and many other *nix users find the current default irritating at best.

- a better approach might be to make the hidden preference more
> accessible and to raise awareness that this behaviour of Firefox can be
> changed.

This would be OK, as well, but I think if you added the option and tracked how many people changed so you can navigate within the URL, you'd find a lot of people changing it.

> This might also have a better chance of getting integrated, avoiding the
> discussion about the proper default.

Documentation of all the various changeable parameters would be another big step in making this easier to deal with.

> The complaints are probably all from recent Windows converts.

Far from it.  I've been a Unix user since 1987 and the current default really makes no sense from a Unix perspective either, as well as being annoying and useless.  What's the point in having keyboard navigation not work within a URL?
Comment 34 User image Anders Conbere 2006-11-13 13:22:04 PST
*** Bug 360601 has been marked as a duplicate of this bug. ***
Comment 35 User image Uri Bernstein (Google) 2006-12-01 07:06:03 PST
*** Bug 362467 has been marked as a duplicate of this bug. ***
Comment 36 User image Martin 2006-12-02 07:05:33 PST
Please change the default. Yes, I changed to linux recently. But it doesn't make sense to have the same (in my opinion) browser work in a different way on the other platform. If I want Gnome-consistency I could use Epiphany. Instead I wanted to use the browser I liked on Windows (ok, I also needed some extentions ;)).
To make the situation even stranger: Internet Explorer selects the entire URL on a double-click, which is different from Firefox. It is one of the more important differences, because it is better usable. Just like tabbed browsing is an improvement, and the find-bar at the bottom side, this is one of those edges over IE. And now on linux I'm stuck with this IE-nonsense again? Give me a break!

Platform-consistency is nice for the default hotkeys and such, but can you please show me what specification shows that a browser URL-bar shouldn't respond to crtl+left/right? 
Comment 37 User image Nicholas Miell 2006-12-24 14:50:18 PST
This needs to be changed. Current behavior (stop_at_punctuation=false) does not match GTK2's behavior and Firefox is theoretically a GTK2 application.

(I was shocked to discover that Windows Firefox gets this right in the urlbar, I always assumed that nobody had ever implemented it. Discovering that Firefox is once-again broken on Linux and correct on Windows is irritating.)
Comment 38 User image Alan Siu-Lung Tam 2006-12-24 21:09:47 PST
Given the amount of positive responses recently, let's try to request for blocking Firefox 3.0. While a patch is available for review already, we are simply waiting for mozilla developers to agree with our view and get it checked in.
Comment 39 User image Matthew Flaschen 2007-01-18 18:23:47 PST
I can verify that Konqueror on KDE GNU/Linux also supports the "true" behavior, so I'm really doubting there is some powerful UNIX standard against it.
Comment 40 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2007-01-22 14:37:09 PST
Not blocking 1.9, but we probably should do this.
Comment 41 User image Martin 2007-01-22 14:53:38 PST
@ #40:
WTF is so difficult about changing a default value in about:config to true for some platform? It's not like anything will break because of that, and (if the code makes any sense at all) it should be only one line changed. 

Can I make this a blocking1.9+ or so? Damn you fools! 38 replies stating that the 1 line of code SHOULD be changed ASAP and it isn't included in the next release? Do some research, it is on all the fora!
Comment 42 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2007-01-22 14:59:35 PST
Don't re-request without new information please.
Comment 43 User image David Baron :dbaron: ⌚️UTC-8 2007-01-22 15:14:48 PST
I'd be quite happy to take a fix for this that didn't regress double-clicking in the URL bar.  That said, the patch above doesn't apply anymore -- the file it's patching no longer exists -- the code in question is now in an ifdef-ed all.js.

Note that on other platforms, there's a browser.urlbar.clickSelectsAll pref -- which we don't want on Unix because it forces a copy to the clipboard.  It seems like the easy solution would be to make a very similar pref for doubleClickSelectsAll (or maybe even change the existing pref from boolean to integer).

For what it's worth, in Konqueror, there seem to be three different selection modes:
 * in the URL bar, double-clicking always selects the whole thing
 * in the search bar and HTML text inputs, double clicking does select punctuation
 * in HTML content, double-clicking does not select punctuation
but Ctrl-Arrow movement always goes by non-punctuation words.  I don't think we need that many modes, but I do think we need to avoid regressing double-click to select contents of entire URL bar.
Comment 44 User image Nicholas Miell 2007-01-22 18:48:46 PST
(In reply to comment #43)
> Note that on other platforms, there's a browser.urlbar.clickSelectsAll pref --
> which we don't want on Unix because it forces a copy to the clipboard.  It
> seems like the easy solution would be to make a very similar pref for
> doubleClickSelectsAll (or maybe even change the existing pref from boolean to
> integer).

That's not how the X clipboard works. Selecting something (i.e. the usual highlighting motion) sticks the selected text in PRIMARY, the Copy menu item (or whatever the equivalent is in the app) puts the selected text on the CLIPBOARD. (See http://www.jwz.org/doc/x-cut-and-paste.html for the definitive explanation, feel free to ignore the Emacs section.)

Mozilla/Firefox have done this wrong in the past, but my quick experimentation in Firefox 2.0.0.1 suggests that it's doing things right at the moment.

(Also, thanks for telling us about browser.urlbar.clickSelectsAll -- now we can manually unbreak that too.)
Comment 45 User image Akkana Peck 2007-01-23 02:57:18 PST
I presume dbaron knows the PRIMARY vs CLIPBOARD issue, and when he said that Unix users don't want single click to copy to the clipboard, he meant the nsClipboard (the general concept of being selected), not the X CLIPBOARD. Changing the PRIMARY selection every time you click in the urlbar would be awful (not that that's the only reason to dislike clickSelectsAll).

As dbaron said, if someone offered a patch that turned on stop_at_punctuation without regressing urlbar doubleclick, I bet everyone would be all for it. (I know I would.) I'm not even sure we'd need a new pref for that -- or do the stop_at_punctuation fans want that setting even when doubleclicking in the urlbar?
Comment 46 User image Martin 2007-01-23 03:44:00 PST
I would. Just like in windows: Double-click selects the word, triple-click selects the entire line. And as a former Windows user I rarely use the x-clipboard function, partially because it is gone when accidentally selecting something else. 
Comment 47 User image Jerry Quinn 2007-01-23 05:59:36 PST
(In reply to comment #45)
> As dbaron said, if someone offered a patch that turned on stop_at_punctuation
> without regressing urlbar doubleclick, I bet everyone would be all for it. (I
> know I would.) I'm not even sure we'd need a new pref for that -- or do the
> stop_at_punctuation fans want that setting even when doubleclicking in the
> urlbar?

I can't think of any scenario where having stop_at_punctuation behavior disabled is desirable.  It's highly counterintuitive to the way that other text UI's work on all platforms.

I'd also want url doubleclick disabled by default (to me doubleclick selecting word-like units is more consistent with other text selection interfaces), but obviously there should be a pref for this one.
Comment 48 User image Uri Bernstein (Google) 2007-02-08 06:45:42 PST
*** Bug 369629 has been marked as a duplicate of this bug. ***
Comment 49 User image Bob Clary [:bc:] 2007-03-19 09:52:06 PDT
*** Bug 374394 has been marked as a duplicate of this bug. ***
Comment 50 User image Uri Bernstein (Google) 2007-04-27 12:21:52 PDT
*** Bug 378988 has been marked as a duplicate of this bug. ***
Comment 51 User image Uri Bernstein (Google) 2007-05-25 08:52:32 PDT
*** Bug 381972 has been marked as a duplicate of this bug. ***
Comment 52 User image Flávio Etrusco 2007-05-25 15:24:48 PDT
Don't you people think it would be "clever" to change the summary to something more descriptive of the perceived problem instead of/additionally to the cause, so we can hope that this endless flow of "bug XXX has been marked as duplicate" will end?
TBH, from the discussion it's clear that the summary and issue originally reported isn't even the whole story...
Comment 53 User image Caio Tiago Oliveira (asrail) 2007-05-26 09:54:46 PDT
Reverting the summary, as Dao nitpicked on personal mail.


The summary of issues derived from the stop_at_pontuation being set to false is:
 - control+arrow should move cursor delete a word
 - double click should select a word

The other are derivate from these two facts.

Comment 54 User image Flávio Etrusco 2007-05-26 11:57:23 PDT
Ok, now I'm ****. Who THE **** is Dao and why does he/she think that this shouldn't be part of the bug entry comments/discussion?
And where's the _unresolved_ BUG (this is not an enhancement) entry for the first problem?
Comment 55 User image Caio Tiago Oliveira (asrail) 2007-05-26 12:21:38 PDT
1 - Be polite
2 - He is a guy
3 - Because it makes harder to read/understand the summary and the people would find the duplicates anyway
4 - It is something that works the way it should work, i.e., this is not an issue. The non-wanted behavior is due to the preference being set false by default on Linux (while it's true on Windows, for instance).

Comment 56 User image Flávio Etrusco 2007-05-27 01:21:17 PDT
1) I usually try very hard to be polite. Problem is "the Mozilla team" is one of the less transparent and less responsive in the open source community. I just HATE secrecy. And the status quo.
2) Thanks.
3) Moot. If you really think like this why did you change it in the first place?
4) Just wrong.

And then, yes, I love Linus Torvalds' "diplomacy". Unfortunately I'm not as respected or known as him =P
TBH I'm asking to be flamed into oblivion so I can just forget about Mozilla as an open source project and stop being laughed at when why try to paint it as an  open project (which has a community).
And I couldn't help being impolite again, but... why don't you stand by your POV and worst yet take the heat that was never meant to you? (I hope it's clear that my "ire" was not ever directed at you, if it seemed otherwise, please accept my apologies.)
Comment 57 User image Dão Gottwald [:dao] 2007-05-28 03:37:19 PDT
I'll post a patch once the urlbar binding from bug 366797 is in the tree.
Comment 58 User image Dão Gottwald [:dao] 2007-06-27 18:46:02 PDT
Created attachment 270107 [details] [diff] [review]
patch v1

So the urlbar binding has landed ... not sure if it will backed out again though. However, for the moment here's a patch.
Comment 59 User image Dão Gottwald [:dao] 2007-07-13 04:38:47 PDT
Created attachment 272151 [details] [diff] [review]
simplified patch, updated to current trunk
Comment 60 User image David Baron :dbaron: ⌚️UTC-8 2007-07-13 14:56:08 PDT
Renominating for blocking given that the new text frame busted URL bar selection.
Comment 61 User image Mano (::mano, needinfo? for any questions; not reading general bugmail) 2007-07-16 13:58:15 PDT
So this is already the default on mac (in Fx2 too), why should the url-bar behave differently on unix?
Comment 62 User image Dão Gottwald [:dao] 2007-07-16 14:58:13 PDT
Mano: Because Linux users are used to select the URL with a double click. I think it was reached consensus over this in this bug: stop_at_punctation=true is wanted, but without making selecting all harder (three clicks), and without setting clickSelectsAll to true.
Comment 63 User image Mano (::mano, needinfo? for any questions; not reading general bugmail) 2007-07-16 15:05:05 PDT
Ok, Ugh, so:
 1. Any reason you're not using an <handler> here (likely with phase="capturing")?
 2. I think this deserves a preference.
Comment 64 User image Mano (::mano, needinfo? for any questions; not reading general bugmail) 2007-07-16 15:07:08 PDT
 3. you should probably override this for SM unless you're fixing their bindings too.
Comment 65 User image Dão Gottwald [:dao] 2007-07-16 16:20:51 PDT
Created attachment 272561 [details] [diff] [review]
patch v2
Comment 66 User image Mano (::mano, needinfo? for any questions; not reading general bugmail) 2007-07-16 16:40:18 PDT
Er, this behavior isn't desired on mac AFAICT.
Comment 67 User image Dão Gottwald [:dao] 2007-07-16 16:46:10 PDT
Created attachment 272565 [details] [diff] [review]
patch v2.1

right
Comment 68 User image Mano (::mano, needinfo? for any questions; not reading general bugmail) 2007-07-21 15:40:56 PDT
What's the use case for doubleClickSelectsAll in textbox.xml? You could do this for the urlbar without extending the binding afaict.
Comment 69 User image Dão Gottwald [:dao] 2007-07-21 17:33:07 PDT
If both #textbox and #urlbar define <handler event="mousedown">, the one defined in #textbox would be of no effect, right? That means that the code from the original #textbox handler would have to be duplicated, if you want me to use <handler>.
Comment 70 User image Mano (::mano, needinfo? for any questions; not reading general bugmail) 2007-07-22 14:35:58 PDT
ok, sorry that I didn't catch that earlier :(, the addEventListener is better than moving this to textbox.xml (preferably with a nsIDOMEventListener implementation on the binding, but simple functions like you had in the first patch would work too).

Again, sorry for the extra-work.
Comment 71 User image Dão Gottwald [:dao] 2007-07-22 16:15:51 PDT
Created attachment 273341 [details] [diff] [review]
patch v3
Comment 72 User image Mano (::mano, needinfo? for any questions; not reading general bugmail) 2007-07-22 16:57:25 PDT
Comment on attachment 273341 [details] [diff] [review]
patch v3

r=mano
Comment 73 User image Mano (::mano, needinfo? for any questions; not reading general bugmail) 2007-07-22 17:11:25 PDT
you need moa on the xpfe/ change.
Comment 74 User image Dão Gottwald [:dao] 2007-07-23 08:29:54 PDT
Comment on attachment 273341 [details] [diff] [review]
patch v3

<NeilAway> dao: so, in other words nothing changes for us... I can't argue with that :-)
Comment 75 User image Jesse Ruderman 2007-07-26 14:54:56 PDT
*** Bug 389516 has been marked as a duplicate of this bug. ***
Comment 76 User image David Baron :dbaron: ⌚️UTC-8 2007-08-03 12:16:25 PDT
Minusing my own blocking request in favor of bug 389421.  (Not to say this shouldn't go in, just that it's not blocking.)
Comment 77 User image Dão Gottwald [:dao] 2007-08-03 19:18:40 PDT
Would be nice if someone could check this in before the diff becomes completely useless. Please let me know if it's already too much out of sync.

I assume approval isn't needed here.
Comment 78 User image Wolfgang Rosenauer [:wolfiR] 2007-08-04 01:17:10 PDT
Comment on attachment 273341 [details] [diff] [review]
patch v3

seems we need approval1.9 to get that in at this stage?
Comment 79 User image David Baron :dbaron: ⌚️UTC-8 2007-08-04 01:22:40 PDT
Comment on attachment 273341 [details] [diff] [review]
patch v3

Not needed for front-end.
Comment 80 User image Wolfgang Rosenauer [:wolfiR] 2007-08-04 01:36:25 PDT
Checked in. Please watch out for regressions.

Checking in browser/app/profile/firefox.js;
/cvsroot/mozilla/browser/app/profile/firefox.js,v  <--  firefox.js
new revision: 1.192; previous revision: 1.191
done
Checking in browser/base/content/urlbarBindings.xml;
/cvsroot/mozilla/browser/base/content/urlbarBindings.xml,v  <--  urlbarBindings.xml
new revision: 1.16; previous revision: 1.15
done
Checking in modules/libpref/src/init/all.js;
/cvsroot/mozilla/modules/libpref/src/init/all.js,v  <--  all.js
new revision: 3.685; previous revision: 3.684
done
Checking in suite/browser/browser-prefs.js;
/cvsroot/mozilla/suite/browser/browser-prefs.js,v  <--  browser-prefs.js
new revision: 1.65; previous revision: 1.64
done
Comment 81 User image Dão Gottwald [:dao] 2007-08-04 01:46:00 PDT
thanks
Comment 82 User image Dão Gottwald [:dao] 2007-08-04 07:52:01 PDT
*** Bug 348787 has been marked as a duplicate of this bug. ***
Comment 83 User image Francesco Montefoschi 2007-08-06 05:32:14 PDT
wow, just 4 years and half

if is helpful, microsoft used 6 years to relase IE 7
Comment 84 User image Jesse Ruderman 2007-11-19 14:03:55 PST
*** Bug 404356 has been marked as a duplicate of this bug. ***
Comment 85 User image Martin 2007-12-23 14:39:36 PST
All right, so this is supposed to be fixed. I've moved to Firefox 3 beta (3.0b3pre, a build by Swiftfox) on Ubuntu 7.04. Love the browser, love the new bookmarks, but HATE the preferences. 

doubleclickSelectsAll is true, which I thought was fought out to be wrong? Or am I reading the discussion in the wrong way? 
Changed that setting to false, so now I have the behaviour I (and many of the comments above) want: singleclick places the cursor, doubleclick selects a word, and tripleclick selects the entire line (like everywhere in every other GTK2 application I know). What is so hard about changing a default? 
Comment 86 User image Jo Hermans 2008-01-02 05:29:52 PST
*** Bug 410475 has been marked as a duplicate of this bug. ***
Comment 87 User image Greg K. 2008-03-13 02:50:42 PDT
One remaining issue for this—on Mac, at least—is that the underscore should not be considered punctuation. This is discussed in bug 393227 which depends on bug 190615.
Comment 88 User image Greg K. 2008-03-13 02:51:54 PDT
Er, make that, “depends on bug 196175.”
Comment 89 User image Dan 2011-12-15 16:56:52 PST
Not to reopen a long dead, thread, but...ok, that's what I want to do.

It seems that this is broken on unix again.  Double clicking selects the whole URL.  The default for:

browser.urlbar.doubleClickSelectsAll

on Unix, is true.  This means that double clicking doesn't stop at punctuation, because it doesn't stop at all, it just selects the whole URL.  So was this whole bug for nothing?

According to this wiki:

http://kb.mozillazine.org/Browser.urlbar.doubleClickSelectsAll

The behavior was changed to restore "double click selects all" on Unix.  But then, how can one double click to select a word?  In windows, the default is different, meaning that double clicking to select a word works.

The wiki states that it required "triple clicking" to select the URL.  In windows, single clicking selects the URL.  Should the same default be considered for Unix?  Even if not, though, there should be a way to select individual words in the URL.  

Again, what was the point of having the "stops on punctuation" setting if not to enable selection of "words"?
Comment 90 User image soshial 2012-02-21 07:38:10 PST
I confirm Dan's words that it is still not default for firefox 10.0.2 on opensuse 11.2 64bit.
Comment 91 User image Craig Turner 2012-03-05 00:56:51 PST
Seen on Ubuntu 11.

There's a difference to previous behaviour. Selecting the URL bar with the keyboard (ctrl+L) allows the user to navigate around that bar stopping at punctuation (ctrl+left, ctrl+right). But a double mouse-click highlights the whole URL rather than words with in.

Triple-click-to-highlight must be annoying the hell out of someone for them to change it back after this time.

Double-click being a unix standard remains a weak argument. Chrome for linux uses double-click to highlight word, triple-click to highlight all. i.e. the same behaviour as in firefox on osx and win32.
Comment 92 User image Martin 2012-03-20 07:50:33 PDT
Apparently nobody that has rights can be bothered to fix this, or even reopen the bug (RESOLVED FIXED no longer matches the status).
Comment 93 User image Boris Zbarsky [:bz] (still a bit busy) 2012-05-23 15:08:30 PDT
This bug is about general selection behavior.  Comment 89 and following is about urlbar selection, which explicitly overrides the default selection behavior.  So they have nothing to do with this bug, which is in fact RESOLVED FIXED.  You can test it by double-clicking "foo" in this text:

  This.is.foo.stuff

and seeing whether it's just "foo" that's selected or the whole string.
Comment 94 User image James M Leddy 2012-11-09 15:19:32 PST
This somehow just bit me as well. I actually want the default unix behavior that requires a tripple click to select the entire address bar. Somehow doubleClickSelectsAll got turned on for me, in Ubuntu 12.04. I think that it's stupid to default this to true in Unix, even if changed behavior when this bug was originally RESOLVED FIXED close to a decade ago.

http://kb.mozillazine.org/Browser.urlbar.doubleClickSelectsAll

On Linux, I have the default of both singleClickSelectsAll and doubleClickSelectsAll to false to closely match the behavior of other apps. I've been using Firefox since it's inception and as far as I can remember this has always been the behavior. 

Is there another bug to request that Linux default to both being false, despite the expectation on other OSes?
Comment 95 User image James M Leddy 2012-11-09 15:21:54 PST
BTW I'm relatively confident that windows by default double click selects the whole text, since I'm frequently frustrated by expecting Linux behavior and getting something else. I'm not sure what the default of IE, chrome, Firefox etc is in the urlbar but I don't think it should really matter, because linux (unix?) users have a different expectation.

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