98546 - Better word-break detection (double-clicking, Control+arrow keys, Control+Backspace/Delete)

Status: VERIFIED FIXED

(Core :: DOM: Selection, defect, P2)

Description

[sujay]

* TITLE/SUMMARY
Heuristics used for selecting double-clicked words are a bit primitive

* STEPS TO REPRODUCE
0) Launch Apprunner
1) Execute the test case located at
http://slip/projects/marvin/selection/double-
click-text/double-click-text-d.html


* RESULT
 - What happened

Sections 4 & 5 fail; the entire chunk of text is selected, rather than just the
word.

 - What was expected

I'm not sure what heuristics Visual Page or Word 98 applications use to
determine
selection boundaries for a double-click.

IMHO, our text editor should be on parity with other editors for intelligence of
double-clicking.


* REGRESSION

 - Occurs On
        Win32 Apprunner (1999101308 optimized build [NT 4, Service Pack 5])
        Linux Apprunner (1999101308 optimized build)
        [Can't check Mac OS Apprunner --- blocked by 14990]

 - Doesn't Occur On
        Visual Page 1.0 (Mac OS)
        Word 98 (Mac OS)


* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).



------- Additional Comments From [e-mail] 1999-10-14 16:14 -------

I would suspect that this is similar to the behavior mentioned in bugs 6875 &
11544. Setting to M15, this can wait until post beta, and setting status to
assigned



------- Additional Comments From Eli Goldberg 2000-01-24 09:57 -------

*** Bug 24773 has been marked as a duplicate of this bug. ***



------- Additional Comments From Eli Goldberg 2000-01-24 10:02 -------

Created an attachment (id=4504)
Test case referenced by URL



------- Additional Comments From Akkana 2000-01-24 12:47 -------

Good test case!  I wonder, though, if it could also include the case of "foo
bar" to check for the issue in bug 11544, that selection incorrectly selects the
space after a word?  Then we could combine all these bugs together.



------- Additional Comments From Eli Goldberg 2000-01-28 13:18 -------

Sorry for slow response, Akkana. Umm...sure. Will do next week.



------- Additional Comments From Eli Goldberg 2000-01-31 16:37 -------

[Note to self: be sure to check Neil's additional examples in bug #24773 when 
verifying this bug.]



------- Additional Comments From [e-mail] 2000-03-06 16:12 -------

reassign to akkana in case she can get to this for M15



------- Additional Comments From Eli Goldberg 2000-03-06 17:15 -------

Ouch! Did I truly procrastinate on this for 10 full weeks? Sorry, Akkana. Test 
case is now added. Please let me know if it's not what you meant.

It's now added to the URL listed above. (which I've also moved to mozilla.org)



------- Additional Comments From Sitsofe Wheeler 2000-03-07 08:19 -------

Is this related to bug 6875?



------- Additional Comments From Akkana 2000-03-13 19:33 -------

*** Bug 6875 has been marked as a duplicate of this bug. ***



------- Additional Comments From Akkana 2000-03-13 19:34 -------

*** Bug 26626 has been marked as a duplicate of this bug. ***



------- Additional Comments From Eli Goldberg 2000-03-14 08:32 -------

[Note to self: be sure to check for unchecked scenarios in Bug 6875 when 
verifying this bug.]



------- Additional Comments From Akkana 2000-03-14 11:32 -------

*** Bug 11544 has been marked as a duplicate of this bug. ***



------- Additional Comments From Akkana 2000-03-27 11:02 -------

Accepting to reduce bugzilla spam, but I don't expect I'll actually have time to
work on this in M15 in addition to my own bugs, so I'll mark it M16 so as not to
create false expectations.



------- Additional Comments From [e-mail] 2000-04-12 18:31 -------

updating keyword and status whiteboard to reflect that this is a beta 2 feature 
work bug that the Composer team deems a must fix for beta 2.



------- Additional Comments From Akkana 2000-04-24 16:22 -------

I'm working on this now ... but I have a question on the "foo" list
demonstrating that words should never include the following punctuation.  Agreed
that Nav 4.x/win does it this way; but other apps on Windows seem to include the
punctuation (though not a trailing space, a bone of contention between Windows
users and other platforms).  On Unix, they're often configurable.

Including the punctuation makes it easier to move through a document using
forward- or backward-word, and also makes it easier to select things like
variable names or urls.  Omitting the punctuation makes it easier to select a
single word to paste into another document.

If we do treat punctuation separately, does that mean that each punctuation mark
should be a separate word, e.g. in the foo!!! example, starting from the
beginning and doing shift-right-arrow would take you to !, another shift-right
would take you to the second !, another to the third, and finally the fourth to
the next word?



------- Additional Comments From Simon Fraser 2000-04-24 16:40 -------

> punctuation (though not a trailing space, a bone of contention between Windows
> users and other platforms).

Mac app's won't show the trailing space selected, but those that do 'Smart copy 
and paste' will add or remove spaces on cutting and pasting text, to preserve a 
space between words at cut/paste boundaries.

> Including the punctuation makes it easier to move through a document using
> forward- or backward-word, and also makes it easier to select things like
> variable names or urls.  Omitting the punctuation makes it easier to select a
> single word to paste into another document.

Mac double-click behaviour is to omit punctuation. However, a different
algorithm 
is used to go forward/back one word, which is (for forward): jump over any 
combination of spaces/puncutation followed by one or more non-puncutation, non-
space characters. So this algorithm takes you to the end of each word in turn, 
jumping over punctuation.

> If we do treat punctuation separately, does that mean that each punctuation
mark
> should be a separate word, e.g. in the foo!!! example, starting from the
> beginning and doing shift-right-arrow would take you to !, another shift-right
> would take you to the second !, another to the third, and finally the fourth
to
> the next word?

For double-click, yes. Double-clicking on a punctuation character selects only 
that character. Double-clicking a space in a run of spaces selects all those 
spaces. Double-clicking a letter selects the run of letters, excluding 
punctuation.



------- Additional Comments From Akkana 2000-04-24 17:13 -------

Sounds like no two platforms are alike, and few apps even on the same platform
necessarily do the same thing.

My inclination right now is to add a hidden pref (initialized once, then saved),
something like selection.wordSeparatorChars.{extend,doubleclick}, to which you
could add characters other than spaces which you wanted to have treated as word
separators in the two different cases.  In case someone reading this is of the
"all prefs are evil" school, this shouldn't be any harder or less efficient than
hardwiring one platform's rules, and much easier than hardwiring several
different platform's rules.



------- Additional Comments From Matthew Thomas (mpt) 2000-04-25 04:22 -------

Akkana, you're exaggerating.

* `Few apps even on the same platform necessarily do the same thing': not true.
  The only difference is between apps which do smart cut and paste, and apps
  which don't. Mozilla should do smart cut and paste in Composer documents, but
  not in text entry fields.

* `In case someone reading this is of the "all prefs are evil" school ...' We're
  not of the `all prefs are evil' school, we're of the `unnecessary prefs should
  be avoided' school. :-) The pref you propose is unnecessary. Just do the same
  thing as every other application does on the particular platform. If you don't
  know what a particular platform does, start a native app on each platform and
  test it.

* `This shouldn't be any harder or less efficient than hardwiring one platform's
  rules, and much easier than hardwiring several different platform's rules.'
  Easier for who??? Certainly not the user. Why should I have to fiddle around
to
  get Mozilla to behave the same as every other app on my OS? Why should it even
  be *possible* for Mozilla *not* to behave the same as every other app on my
OS?

MacOS word selection heuristics are at <http://developer.apple.com/techpubs/mac/
HIGuidelines/HIGuidelines-217.html> (about 1/3 of the way down the page).
I'd tell you where the Windows ones are, but the
<http://msdn.microsoft.com/library/> applet doesn't work properly on MacOS ...



------- Additional Comments From Eli Goldberg 2000-04-25 08:24 -------

[I have no meaningful opinion to add; the expected results that I provided
mostly 
came from experimenting with commonly used apps like Microsoft Word.]



------- Additional Comments From Alistair Vining 2000-04-25 09:34 -------

http://msdn.microsoft.com/isapi/msdnlib.idc?theURL=/library/books/winguide/ch06c
.htm

"Selection Shortcuts

Double-clicking with the primary mouse button is a shortcut for the default 
operation of an object. In text contexts, it is commonly assigned as a shortcut 
to select a word. When supporting this shortcut, select the word and the space 
following the word, but not the punctuation marks."

FWIW.



------- Additional Comments From Akkana 2000-04-25 10:37 -------

To address Matthew's points:
1. Yes, I was exagerating, but it is true that on each platform, one can find
two very commonly-used apps which use different rules.
2. The pref isn't unnecessary, unless you want me to clutter the code with
platform #ifdefs.  That's just silly and there's no reason for it.  If we have
to support many different standards anyway, then implementing with a pref is
easier as well as better.  Close your eyes and pretend I compiled in lots of
ifdefs if it makes you feel better.
3. Easier on users who use only one platform: defaults will be set appropriately
for each platform and there's less risk of their being wrong because they can be
easily tuned for each platform.
Easier on users who use multiple platforms: they have the option of having it
work the way they like everywhere they use mozilla.
Easier on people porting to other platforms: it's done, just tune the pref, no
need to add another #ifdef and get it approved for checkin.
Easier on someone trying to read the code: no ugly maze of ifdefs.
Basically, easier on everyone.  I can't think of a counterexample.



------- Additional Comments From Matthew Thomas (mpt) 2000-04-27 04:09 -------

Ok Akkana, you win. I withdraw and apologize. :-)



------- Additional Comments From Akkana 2000-04-27 14:21 -------

No problem, and sorry for my exaggerations earlier.  Let's get the defaults
right on all platforms, and I'm glad you're around to keep me honest. :-)



------- Additional Comments From Phil Peterson 2000-05-05 16:19 -------

[nsbeta2-]



------- Additional Comments From [e-mail] 2000-05-09 11:06 -------

m17



------- Additional Comments From Akkana 2000-05-15 18:17 -------

The feature has long been in place; what's left is just tuning of which
characters end a word.  Changing whiteboard accordingly.



------- Additional Comments From Akkana 2000-05-24 17:39 -------

*** Bug 40490 has been marked as a duplicate of this bug. ***



------- Additional Comments From Ben Bucksch 2000-05-24 18:01 -------

From the DUP bug:

Reproduce:
1. Type "bla1 bla2 bla3" in editor
2. Doubleclick on "bla2" (will select "bla2")

Actual result:
"bla2 " will be selected

Expected result:
"bla2" will be selected

Why this matters:
Apart from the fact, that the latter makes more sense to me and produces better
HTML source, the former also breaks the HTML->TXT converter for bold, strong,
italic etc.. I see no way to fix the converter.
Try this: Mark the selected text bold and do Debug|OutputText.
You'll see "bla1 *bla2 *bla3". This is wrong. It should be "bla1 *bla2* bla3".
The latter can be recognized by the TXT->HTML converter (try it in Mailnews) and
humans knowing this convention.

IMO, we can't ship with the converter producing such nonsense. We need to
fix either this bug or find a kludgy workaround in the converter.



------- Additional Comments From [e-mail] 2000-07-27 06:13 -------

setting to nsbeta3+



------- Additional Comments From [e-mail] 2000-07-27 16:36 -------

adding brackets to status whiteboard



------- Additional Comments From [e-mail] 2000-07-31 13:59 -------

setting priority in status whiteboard



------- Additional Comments From Blake Ross 2000-08-14 16:49 -------

*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
[e-mail] to [e-mail].  After the many great years of service 
Eli has given to Mozilla, it's time for him to move on; he has accepted a 
position at Eazel.  We'll be sad to see him go, and I'll do my best to fill his 
spot...



------- Additional Comments From [e-mail] 2000-08-23 10:27 -------

setting to future, this will have to wait until the next release, or if someone 
will step up and help out on this one



------- Additional Comments From Matthew Thomas (mpt) 2000-10-21 05:53 -------

*** Bug 43846 has been marked as a duplicate of this bug. ***



------- Additional Comments From Akkana 2000-10-24 16:03 -------

Anthony is taking over selection bugs.



------- Additional Comments From Jesse Ruderman 2000-11-19 00:14 -------

*** Bug 60613 has been marked as a duplicate of this bug. ***



------- Additional Comments From Jesse Ruderman 2000-11-19 00:16 -------

*** Bug 56402 has been marked as a duplicate of this bug. ***



------- Additional Comments From Jesse Ruderman 2000-11-19 00:20 -------

about ten dups, adding mostfreq keyword.



------- Additional Comments From [e-mail] 2000-11-29 14:44 -------

setting milestone to be mozilla 1.0



------- Additional Comments From [e-mail] 2000-11-29 16:35 -------

marking to Future, but this needs to be investigated (alnog with several other 
selection behaviour bugs) its a sure bet we will not be able to satisfy everyone 
on these behaviour bugs.

anthonyd



------- Additional Comments From Simon Fraser 2000-11-29 17:01 -------

I don't think this should be future. The bugs here are annoying enough to 
interfere with editing, as the keywords suggest.



------- Additional Comments From Akkana 2000-11-29 17:27 -------

I don't think there will be much problem satisfying people (in fact, ideally, we
should be able to store the list of chars which define words and make it easily
changeable, so that people can get the behavior they're used to on any given
platform).  The real difficulty with this bug is someone spending the time to
understand why it's broken now (e.g. now sometimes double-click gives you
several space-separated words, which clearly was never the intent on any
platform) and insert working code; tweaking it later to add and subtract
characters will be a minor issue.



------- Additional Comments From [e-mail] 2000-11-29 17:28 -------

per simon, marking bug as 0.9.  I'll be bothering platform specific people to 
get the most acceptable/correct behaviour and fix this.

anthonyd



------- Additional Comments From sairuh (se) 2000-12-05 15:32 -------

sometimes when i doubleclick in the URL textfield, the selection goes from the
beginning of the field to where the cursor is --rather than the entire URL field
contents. [annoyingly inconsistent] akkana mentioned that this and bug 47469 are
prolly the cause of that.



------- Additional Comments From Jesse Ruderman 2000-12-10 13:45 -------

I think the location bar problem is bug 16203.



------- Additional Comments From [e-mail] 2001-01-11 14:26 -------

removing nsbeta



------- Additional Comments From [e-mail] 2001-01-19 11:59 -------

lowering the priority to p3



------- Additional Comments From [e-mail] 2001-02-12 14:41 -------

adding nsmac1 keyword



------- Additional Comments From [e-mail] 2001-03-26 13:38 -------

moving to mozilla1.0



------- Additional Comments From Terri Preston 2001-04-09 13:59 -------

*** Bug 66574 has been marked as a duplicate of this bug. ***



------- Additional Comments From R.K.Aa 2001-04-15 21:16 -------

*** Bug 76127 has been marked as a duplicate of this bug. ***



------- Additional Comments From R.K.Aa 2001-04-15 21:24 -------

Linux: not only is punctuation and a trailing whitespace copied - two extra
linefeeds are added as well.

Test this by double-clicking a word in the middle of a sentence in an existing
bug comment. Then paste it into an external editor.

Copy from the context-menu shows same behaviour.





------- Additional Comments From timeless@linuxworld:/vacation 2001-04-15 23:19
-------

The extra linebreak on linux is a separate bug.

w32nc4.76 double clicking on an exclamation mark in this!!! results in the 
three !'s being selected.



------- Additional Comments From [e-mail] 2001-06-28 14:39 -------

*** Bug 88228 has been marked as a duplicate of this bug. ***



------- Additional Comments From [e-mail] 2001-07-03 16:33 -------

*** Bug 89120 has been marked as a duplicate of this bug. ***



------- Additional Comments From [e-mail] 2001-07-03 16:34 -------

*** Bug 89124 has been marked as a duplicate of this bug. ***



------- Additional Comments From Jesse Ruderman 2001-07-04 03:28 -------

*** Bug 47469 has been marked as a duplicate of this bug. ***



------- Additional Comments From earthsound 2001-07-09 14:46 -------

Specs: Win 98 build 2001062815

Observation #1: double clicking the first half of the first letter in the second
word of any combination of two words will result in both the word clicked & word
preceding it to be highlighted. 

#2: In the following example, three(!) words are highlighted when the first a in
appear is double clicked:
these...three appear

Reproducibility: Everytime

Results expected: In Win98, this behavior is NOT exhibited in: notepad (the
preceding word & space is highlighted), wordpad (the double clicked word is
highlighted), MS Access 2000 v9.0.4402 SR-1 (same as notepad), IE 5.50.4522.1800
(same as wordpad), Netscape 4.76 (same as wordpad), MS Word 2000 v9.0.4402 SR-1
(same as wordpad), Netscape 3.04 (same as wordpad), AbiWord Personal 0.7.14
(same as wordpad), Dreamweaver 3.0 (same as wordpad)



------- Additional Comments From [e-mail] 2001-07-31 15:22 -------

kevin and sol,
this bug has been around a long time, and the general problem is expected 
behaviour.  any input would be helpful.

think about the following examples for both double click and triple click:
single words
numbers
table cells
mixed content in table cells
<p> tags
<body> tags
list items (both ordered and unordered)
special characters in content
punctuation
etc.

all of these behave differently, and nobody seems to like our current behaviour.
any help would be appreciated guys.

anthonyd



------- Additional Comments From Akkana 2001-07-31 15:43 -------

A good start would be just to get double-click doing anything repeatable (e.g.
use space as separator, or use nsILineBreaker to decide).  Right now, about half
the time when I double-click in the urlbar, it selects from the beginning of the
text field to the mouse position, which is obviously a bug and is a usability
problem.  Earthsound's recent comment describes a different problem which is
probably related.  (Poke around the bugs duped to this bug to see other examples
of bad unpredictable behavior on double-click, probably all related.)

Completely aside from what the subtle rules should be, fixing the current bugs
and perhaps locating the code that handles doubleclick selection and isolating
it in one place (so it can be modified once we know the complete rules) would be
a big win.



------- Additional Comments From Mike Pinkerton 2001-07-31 15:51 -------

here's something that really bugs me. if i have the following text:

foopy). Doopy.

In 4.x, if i double-click the word "foopy" this is what is selected (indicated
by 
|'s)

|foopy|). Doopy.

In ns6, I get:

|foopy). |Doopy.

which is just plain wrong. No other app does anything like this. It also forces 
me to re-type a lot of punctuation when i'm substituting words.



------- Additional Comments From earthsound 2001-08-01 11:25 -------

Fwiw, notepad on Win98 behaves like Mozilla (i.e. highlighting {foopy). } in
Mike's foopy example. (Not that Notepad is something Mozilla should emulate:)

Suggestion: treat punctuation and alphanumericals separately, i.e. if
double-clicking (dc) or Shift+Ctrl+arrowing words to highlight, group
accordingly:

foo.com!). "Forget about it".
- doubleclicking foo should highlight foo only
- Shift+Ctrl+arrowing from the beginning should highlight {foo}, then the {.},
then {com}, then the {!). }[up to the quotation mark], then the {"}, then
Forget, etc.
- doubleclicking Forget should highlight {Forget} without the quotation mark

another example:
(text/html)
- "text" should be highlighted when doubleclicked, the whole [including ( & )]
should be highlighted on the *third* click

It appears (from an end-user perspective) as though the heuristic is only
looking for the next upcoming white space when determining what gets highlighted
via either doubleclicking or Shift+Ctrl+arrowing.



------- Additional Comments From Mike Pinkerton 2001-08-01 12:55 -------

ew, if that selection behavior is the win32 way, then we need some ifdef code or 
a nsILookAndFeel to change that for Mac. It's very unsettling how mozilla does 
word selection differently from every other mac application. 



------- Additional Comments From Mike Stockman 2001-08-01 13:28 -------

[Not sure if this should be a separate bug or part of this one, but it's fits
the Summary... please correct me if this doesn't belong here.]

Double-click-and-drag behavior is pretty broken, too.

To demonstrate, double-click a word in a paragraph and, with the mouse still
down from the double-click, drag left or right.

Expected behavior: the selection should be extended word-by-word as you drag.

Actual behavior: the selection is extended character-by-character, as if you had
just clicked-and-dragged.



------- Additional Comments From [e-mail] 2001-08-01 13:52 -------

the dbl-click drag behavior is bug #16203

I believe the current strategy is to have a pref with the various platform 
possibilities for word breaks.  I'm not really sure that strategy will work, 
especially if you look at what the HIG are for Macintosh:
http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-217.html

You'll see that the expectation there is that (for example) commas and periods 
when in numbers are considered to be part of the "word" but they wouldn't be in
a 
sentence with words.  Also, I'd worry about localization and
internationalization 
issues.



------- Additional Comments From Akkana 2001-08-01 14:35 -------

The windows word selection is just as unsettling to Unix users as to mac users.
 It's clear that we should have different behavior per platform (and perhaps per
context), and that part is easy.

The problem is that right now, the word/line/paragraph code is spread all over
the frame code and nobody understands it well enough to fix the current bugs in
it or collect all the word breaking decision code into one place so that rules
like this could be applied to it.  That would also help localization, since then
the nsILineBreaker interface could be used.  Fix that, and I'll happily
volunteer to do the platform split (which could then be tuned by UE and platform
people).



------- Additional Comments From Matthew Thomas (mpt) 2001-08-27 07:28 -------

*** Bug 79409 has been marked as a duplicate of this bug. ***



------- Additional Comments From Matthew Thomas (mpt) 2001-08-27 07:29 -------

*** Bug 76619 has been marked as a duplicate of this bug. ***



------- Additional Comments From [e-mail] 2001-08-29 15:48 -------

--> mjudge

Comment 1

[sujay]

*** Bug 16352 has been marked as a duplicate of this bug. ***

Comment 2

[Kathleen :Brade]

testcase at this location: 
  http://bugzilla.mozilla.org/attachment.cgi?id=4504&action=view

Comment 3

[Tuukka Tolvanen (sp3000)]

*** Bug 98966 has been marked as a duplicate of this bug. ***

Comment 4

[Mike Pinkerton (not reading bugmail)]

Attachment: make it behave correctly on mac

Comment 5

[Mike Pinkerton (not reading bugmail)]

Attachment: updated patch with prefs instead of ifdefs

Comment 6

[Mike Pinkerton (not reading bugmail)]

i know this patch isn't the best, but it's a good 90% solution for now. i
suggest we get this patch in and leave the bug open for a real rewrite to do the
right thing.

needing r/sr.

Comment 7

[Scott Collins]

Comment on attachment 54064 [details] [diff] [review]
updated patch with prefs instead of ifdefs

Looks good to me.  sr=scc

Comment 8

[Simon Fraser [no longer active]]

Comments:
+pref("editor.word_select.eat_space_to_next_word", false);
+pref("editor.word_select.stop_at_punctuation", true);

Isn't this a layout pref, rather than an editor pref? It also affects selection 
in browser windows, I presume.

+PRPackedBool nsTextFrame::sWordSelectPrefInited = PR_FALSE;
+PRPackedBool nsTextFrame::sWordSelectEatSpaceAfter = PR_TRUE;

Why do we need these prefs in two places (nsTextTransformer, and nsTextFrame)? It 
seems broken that both classes share text selection logic. Mjudge?

If we really need those prefs in nsTextFrame, then maybe you should make use of 
nsPresContext's pref cacheing (nsIPresContext::GetCachedBoolPref()).


+              aPos->mEatingWS = PR_TRUE;
+              if (!isWhitespace){
+                                       while (tx.GetNextWord(PR_FALSE, &wordLen, 
&contentLen, &isWhitespace, &wasTransformed, PR_TRUE, PR_FALSE))
+                                       {

etc.

If you're touching those lines, you might as well detab them.

I'm pretty scared to sr this without knowing why the logic has to be in 2 places.
mjudge, please weigh in here.

Comment 9

[mjudge]

caching is good.
the pref should be layout not editor

the pref for eating white space when selecting needs to be in nsTextFrame.
the pref for the checking where a word breaks lives in nsTextTransformer.  
Not real sure how to change it to only put "logic in one place".  The idea is 
that we might want windows users to also abort selecting on a punctuation but 
some windows apps still select the space after the word..

MJ

Comment 10

[Mike Pinkerton (not reading bugmail)]

Attachment: fix up tabs, change to layout pref

Comment 11

[Mike Pinkerton (not reading bugmail)]

ok, big section detab'd. changed pref to layout.word_break.*. after talking to
dbaron, he suggested that I leave the prefs the same as making a cached pref
ends up touching nsIPresContext.

can i get final r/sr love?

Comment 12

[mjudge]

I like it. I realize that the logic is kinda in 2 places but they 
both start with nsText... ;)
r= mjudge

MJ

Comment 13

[Simon Fraser [no longer active]]

Comment on attachment 54096 [details] [diff] [review]
fix up tabs, change to layout pref

sr=sfraser

Comment 14

[Mike Pinkerton (not reading bugmail)]

ok, my patch is checked in. leaving this bug open because a lot of work still
needs to be done in this area.

Comment 15

[Akkana Peck]

Pink: you're a god.  Thank you!  But you only changed mac, not Unix.  Windows is
the only platform that wants the space added.  

I suggest we make your mac settings the default, and set the windows settings
differently.  (My impression is that not even all Windows programs behave that way.)

Comment 16

[Akkana Peck]

Attachment: Patch: fix unix, make mac/unix the default

Comment 17

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 54273 [details] [diff] [review]
Patch: fix unix, make mac/unix the default

r=pink

Comment 18

[Akkana Peck]

Whups, running with that for a little while I realized that Unix browsers
typically don't stop at punctuation (makes life difficult in the urlbar), though
editors often do.  So:

Index: unix/unix.js
===================================================================
RCS file: /cvsroot/mozilla/modules/libpref/src/unix/unix.js,v
retrieving revision 3.49
diff -r3.49 unix.js
70a71,73
> // override double-click word selection behavior.
> pref("layout.word_select.stop_at_punctuation", false);
> 

Comment 19

[Simon Fraser [no longer active]]

Comment on attachment 54273 [details] [diff] [review]
Patch: fix unix, make mac/unix the default

sr=sfraser

Comment 20

[Daniel H. S.]

*** Bug 79409 has been marked as a duplicate of this bug. ***

Comment 21

[sujay]

Marking nsbeta1+ per syd. Need to fix for composer usability.

Comment 22

[:deanis74]

From looking at lxr, I assume this was checked in?  I think it caused bug
108125, which is really annoying.

Comment 23

[:deanis74]

It does if you enable the layout.word_select.stop_at_punctuation pref, which I
guess I must have done at some point!

Comment 24

[:deanis74]

Umm, ignore that.  Wrong bug.  Sorry for the spam.

Comment 25

[Charles Manske]

Comment on attachment 54273 [details] [diff] [review]
Patch: fix unix, make mac/unix the default

This was checked in.

Comment 26

[Alfonso Martinez]

*** Bug 121838 has been marked as a duplicate of this bug. ***

Comment 27

[Alfonso Martinez]

*** Bug 122397 has been marked as a duplicate of this bug. ***

Comment 28

[Alfonso Martinez]

*** Bug 123815 has been marked as a duplicate of this bug. ***

Comment 29

[Michael Wardle]

Does anybody have an opinion of what the double and triple click selection
should do in the URL bar?  I recently filed bug 125172, stating that I believe
that double-click in the URL bar should also select a word, as it does in other
text fields (this behaviour may differ depending on the state of clickSelectsAll).

Testing something raised in this bug's summary, I tried clicking in the URL bar
somewhere in the middle and control-left arrowing, and it selects all the text
from the text insertion point/"I" bar character, rather than selecting back to
the start of that word.

Does word breaking occur in the URL bar, should it, and is it functioning correctly?

Comment 30

[Adam Lock]

What's a word in the address bar?

If it means something delimited by a space, ':', '/', '#', '&', '+' or '?' then
I think it would be useful functionality, though not necessarily for the
double-click behaviour. Perhaps ctrl double-click or something like that would
invoke it.

Comment 31

[timeless]

those sound like the right delimiters, one note they should all be treated as a 
single character so as far as ctrl-right navigation, i'll mark landing spots w/ 
*.  However, I think you should add = and ; to the delimiters.

*http://*www.*mozilla.*org/*projects/*quality/*test/foo?&*a=*b;*c=*d#*h

Comment 32

[Akkana Peck]

Double-click should select a word (if clickSelectsAll is off).  (Exactly what
characters are word delimiters is a subtlety, and ideally it should be
configurable, but first we have to get the basic behavior working.)

Right now, sometimes it selects a word, and sometimes (way too often!) it
selects from the beginning of line to the current caret position.  To me that's
the #1 issue in this bug since it makes all the other subtleties meaningless.  I
really hope the nsbeta1+ means that at least that part of the bug can be fixed
before we release.

Comment 33

[Michael Wardle]

A quick reply to comment 30:

Adam, the main delimiter I was thinking of was in fact "." (period / full stop).
 In standard text, a period (does/should) delimits an end of sentence, and
clearly words do not extend over sentence markers.

I suggest this because it should be consistent with other text fields, but also
because double click could then be used to select a host, domain, or directory
with ease.  (In all text fields, the entire line can be selected by triple
clicking, or positioning the cursor at the start of the line and shift-ending.)

I'm guessing you just forgot to mention ".", but I wanted to clear that up.

Comment 34

[:deanis74]

Akkana: That's a separate bug, perhaps bug 114445.

Comment 35

[Akkana Peck]

Bug 114445 is about drag-selecting being more mac-like, and doesn't say anything
about double-clicking.  This bug is about double-clicking doing the right thing,
no?  Bug 125172 is also a good description of what double-click should do.

Comment 36

[Ben Ruppel]

in reply to #33, when would anyone want to select only the hostname without the
.com or .org in the urlbar?  Isn't it the more frequent case to want the entire
host name?

Comment 37

[timeless]

http://www.whitehouse.com/ ctrl-left, gov. <enter>
there are lots of other reasons, but the general idea is that DNS is at 
least as hierarchical as webserver paths (ideally much more so).

Comment 38

[rubydoo123]

removing myself from the cc list

Comment 39

[Alfonso Martinez]

*** Bug 131419 has been marked as a duplicate of this bug. ***

Comment 40

[justin hugh daly]

adding to cc list

Comment 41

[Jesse Ruderman]

*** Bug 139346 has been marked as a duplicate of this bug. ***

Comment 42

[Jesse Ruderman]

*** Bug 141536 has been marked as a duplicate of this bug. ***

Comment 43

[Jesse Ruderman]

*** Bug 143568 has been marked as a duplicate of this bug. ***

Comment 44

[Jesse Ruderman]

*** Bug 146914 has been marked as a duplicate of this bug. ***

Comment 45

[Andrew Hagen]

What's the status of this bug? There was a fix checked in, but the status is
new. In the testcase, using 1.0RC3, many of the double-click selections work
right, but others do not. 

Comment 46

[Jesse Ruderman]

*** Bug 149928 has been marked as a duplicate of this bug. ***

Comment 47

[Kathleen :Brade]

*** Bug 151131 has been marked as a duplicate of this bug. ***

Comment 48

[Jesse Ruderman]

*** Bug 153184 has been marked as a duplicate of this bug. ***

Comment 49

[Jesse Ruderman]

*** Bug 152988 has been marked as a duplicate of this bug. ***

Comment 50

[Jesse Ruderman]

*** Bug 121123 has been marked as a duplicate of this bug. ***

Comment 51

[Jeremy M. Dolan]

For comparisons sake, I've configured my xterm to break on the following:

rxvt.cutchars:   `"'()[]{}<>,;|

(those are of course in addition to whitespace)

I've been using this setting for quite some time, and it's very good at DWIM. It
selects URLs and e-mail addresses very nicely, as well as file paths, and lot of
other things you'd want to select as one piece.

MY PHILOSOPHY: It's better to select too much, then too little. If you have
"foo.bar", for example, and double-click only gives you "foo", well, a user
could have drag-selected a measly three characters anyway. The setting above
have given me relatively few hassles at such things. Except C-net URLs with
stupid freaking commas in them. But it's evolved well, and the benefit of
breaking on , in regular English usage outweights c-net.

Comment 52

[Olav Vitters]

*** Bug 156669 has been marked as a duplicate of this bug. ***

Comment 53

[Jesse Ruderman]

*** Bug 162304 has been marked as a duplicate of this bug. ***

Comment 54

[Daniel Wang]

*** Bug 165007 has been marked as a duplicate of this bug. ***

Comment 55

[Daniel Wang]

should we reopen some of the dupes so that they are more discoverable
(to reduce # of new duplicates)?

Comment 56

[Alfonso Martinez]

*** Bug 165472 has been marked as a duplicate of this bug. ***

Comment 57

[Adam Hauner]

Reseting outdated target milestone.

Comment 58

[Aaron Leventhal]

*** Bug 168190 has been marked as a duplicate of this bug. ***

Comment 59

[Jeff Hooker]

removed jhooker from cc: list

Comment 60

[Alfonso Martinez]

*** Bug 171418 has been marked as a duplicate of this bug. ***

Comment 61

[Greg K.]

*** Bug 172648 has been marked as a duplicate of this bug. ***

Comment 62

[Sergey Sokoloff]

Just looking at the URL http://bugzilla.mozilla.org/show_bug.cgi?id=98546 I
suggest that not only space, ':', '/', '#', '&', '+' or '?' be delimiters
(according to Additional Comment #30 From Adam Lock), but also equal sign ('='),
whick will be useful for remote debugging e.g. CGI scripts.

I wish I could change bug priorities ;-) lots of people use URL-cutting when
they get 404 error, but now they are stuck with BackSpace-only techique in their
Mozillas...

Comment 63

[Jesse Ruderman]

*** Bug 174837 has been marked as a duplicate of this bug. ***

Comment 64

[Daniel Wang]

*** Bug 175940 has been marked as a duplicate of this bug. ***

Comment 65

[Daniel Wang]

*** Bug 174453 has been marked as a duplicate of this bug. ***

Comment 66

[Dan Reif]

Being naughty and copying some dupe text into the main bug, but it's good
documentation....

One of the nicer features of IE is its ability to allow easy keyboard-only
editing of URIs in the address bar.  One of the ways this is accomplished is
with CTRL modification of the behavior of keyboard-controlled highlighting.

A short (basic) summary of IE's block-highlight behavior:
if ( shift_key )
{
    if ( ctrl_key )
    {
        add the character immediately to the (arrow keypress direction) of the
cursor to the selected text;
        while ( next character in that direction is not an element of { '/',
'+', '&', '.', ':' } )
        {
            add that character to the selection;
        }
    }
}

Comment 67

[Michael Lefevre]

*** Bug 167839 has been marked as a duplicate of this bug. ***

Comment 68

[R.K.Aa.]

*** Bug 179850 has been marked as a duplicate of this bug. ***

Comment 69

[:deanis74]

Just to throw a wrench into things, 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.

Comment 70

[Greg Dougherty]

One problem I don't see mentioned anywhere in the comments is that Mozillia does
"word detection" differently going forward and backwards.  Going backwards, it
looks for whitespace, while going forward, it looks for a word break character,
which leads to ugly and inconsistent results.  For example:

"happy"
a test bugzilla.mozilla.org

If you double-click on the first line, it selects "happy
If you double-click on bugzilla, that is what is selected.  If you double-click
on mozilla, however, bugzilla.mozilla is selected.  That inconsistent behavior
is BAD.

Greg

Comment 71

[Jesse Ruderman]

*** Bug 180332 has been marked as a duplicate of this bug. ***

Comment 72

[Sébastien Delahaye]

*** Bug 180572 has been marked as a duplicate of this bug. ***

Comment 73

[Jan Moesen]

I guess I'll read the outcome of this bug in Mozilla 2.1's release notes. :-)
Happy hacking.

Comment 74

[Sébastien Delahaye]

*** Bug 182097 has been marked as a duplicate of this bug. ***

Comment 75

[Jo Hermans]

*** Bug 184325 has been marked as a duplicate of this bug. ***

Comment 76

[Cyrus Patel]

removed myself from cc

Comment 77

[Jo Hermans]

*** Bug 185209 has been marked as a duplicate of this bug. ***

Comment 78

[Jo Hermans]

*** Bug 185667 has been marked as a duplicate of this bug. ***

Comment 79

[Aaron Leventhal]

Revisiting this bug, because Ctrl+[shift]+arrow is not behaving satisfactorily
in URL bar.

Wasn't this supposed to be set to true in winprefs.js? Why was it checked in as
false?
pref("layout.word_select.stop_at_punctuation", false);

Setting it to true on my win2k system, however, ctrl+[shift]+right makes it stop
twice as often as it should. In the URL bar, the caret should only stop right
before a letter, when moved by word. Ctrl+[shift]+left is moving all the way to
the start of the URL bar.

Is the standard on Mac and UNIX system to not stop at punctuation, even in the
URL bar?

Comment 80

[Aaron Leventhal]

Attachment: Fixes pref layout.word_select.stop_at_punctuation, selects correct amoiunt of text for ctrl+[shift]+arrow, or double click on word. Needed to add new params to some methods.

Comment 81

[Aaron Leventhal]

Taking. If someone could try this on a mac I'd appreciate it.

Comment 82

[Akkana Peck]

The default in all.js is true.  So if you want windows to be true, just remove
the line from winpref.js.  But perhaps someone (mjudge?) doesn't agree with you
and thinks the windows default should be false ... be sure to check with other
windows users to be sure you have agreement.

I'm not clear on what the rest of this does -- does this fix the problem of
forward vs. backward selection being different?  (There's a separate bug on that
specific issue, actually two of them: bug 181926 and bug 142120.)

> Is the standard on Mac and UNIX system to not stop at punctuation, even in the
> URL bar?

The Unix standard is that doubleclick in the urlbar stops at spaces but doesn't
stop at punctuation (you generally want to select http:// and
&id=98546,format=normal as part of the url).

I just tried an existing mozilla on mac (my tree there is old, can't immediately
try the patch): mozilla selects inconsistently with doubleclick (sometimes it
selects the whole url, more often it selects from the beginning of the url up to
the next punctuation mark to the right of the cursor); IE stops at punctuation
in both directions.  This might be a symptom of the "different in forward and
reverse directions" bugs mentioned previously.

Comment 83

[:deanis74]

> be sure to check with other windows users to be sure you have agreement.

I'm all in favor of having this the default on Windows.  IE has this in all its
text fields, as do other parts of windows such as the common dialogs and Start >
Run.

Comment 84

[Greg Dougherty]

Standard behavior on Mac is that just about any non-alphanumeric character
(other than a non-breaking space (supposed to be entered with shift-<space>)
provides "word break" when double-clicking.  With Communicator, in the URL bar,
"." is not considered a "word break" character, which always struck me as the
correct behavior.  Currently, Mozilla Mac DOES consider "." to be a "word
break".  I'd love to see that change, but since I can't get the Mozilla build
system to install on my Mac, I can't fix it.

Comment 85

[Aaron Leventhal]

As Dean says, the windows pref should be stop at punct. I'll remove the line
from winprefs.js since all.js covers it.

> I'm not clear on what the rest of this does.
A lot of the code just deals with the fact that a new param was in nsPeekOffset
struct (PRBool mRequireNonPunct) so that nsTextTransformer methods would know
whether move by word should require stopping at an alphanumeric char.  For
doubleclick, this is false. For Ctrl+[shift]+right it is true, and it will stop
at the first alphanumeric char after a punctuation or space.

> I just tried an existing mozilla on mac ... [for doubleclick] it selects from
the beginning of the url up to> the next punctuation mark to the right of the
cursor);
This should defintely fix that problem - I didn't have a mac, but when I looked
at the code, I thought it would do that. The new code fixes doubleclick for
pref("layout.word_select.stop_at_punctuation", true);

> does this fix the problem of forward vs. backward selection being different?  
> (There's a separate bug on that 
> specific issue, actually two of them: bug 181926 and bug 142120.).
No, it doesn't fix those problem. They have to do with
pref("layout.word_select.eat_space_to_next_word", false);
I tried Alt+shift+arrow on mac osx to see how it behaves. It behaved differently
in all 3 places I tried it - IE address bar, IE text edit field at the TextEdit
app that comes with IE. In text edit, it stops before the space when going to
the right, but after the space when moving left. Maybe smfr can give more input
on those  bugs, but they're not so related to this one, which is more to do with
punctuation.

Comment 86

[Kathleen :Brade]

Comment on attachment 110258 [details] [diff] [review]
Fixes pref layout.word_select.stop_at_punctuation, selects correct amoiunt of text for ctrl+[shift]+arrow, or double click on word. Needed to add new params to some methods.

>Index: modules/libpref/src/win/winpref.js
>-pref("layout.word_select.stop_at_punctuation", false);
>+pref("layout.word_select.stop_at_punctuation", true);
You shouldn't need to add this in; deletion should be sufficient (since it's in
all.js)
I'm a little wary of making this change but I'd have to check back to the
original bug that caused this pref to be introduced in the first place.


>Index: content/base/src/nsSelection.cpp
>@@ -1605,7 +1605,8 @@
> 
>   //set data using mLimiter to stop on scroll views.  If we have a limiter then we stop peeking
>   //when we hit scrollable views.  If no limiter then just let it go ahead
>-  pos.SetData(mTracker, desiredX, aAmount, eDirPrevious, offsetused, PR_FALSE,PR_TRUE, PR_TRUE, mLimiter != nsnull);
>+  pos.SetData(mTracker, desiredX, aAmount, eDirPrevious, offsetused, PR_FALSE,
>+              PR_TRUE, PR_TRUE, mLimiter != nsnull, PR_TRUE);
> 
>@@ -2721,7 +2722,7 @@
>       //set data using mLimiter to stop on scroll views.  If we have a limiter then we stop peeking
>       //when we hit scrollable views.  If no limiter then just let it go ahead
>       pos.SetData(mTracker, 0, eSelectDir, eDirNext, startPos, PR_FALSE,
>-                  PR_TRUE, PR_TRUE, mLimiter != nsnull);
>+                  PR_TRUE, PR_TRUE, mLimiter != nsnull, PR_FALSE);

Why the difference above for PR_TRUE in first case and PR_FALSE in second case?
 Would more context in this file be helpful?


>Index: layout/base/public/nsIFrameSelection.h
>@@ -122,6 +124,7 @@
>   PRBool mPreferLeft;
>   PRBool mJumpLines;
>   PRBool mScrollViewStop;
>+  PRBool mRequireNonPunct;
> };

Can we change all of the above (certainly the two you are changing) to
PRPackedBool?



>Index: layout/html/base/src/nsPresShell.cpp
>@@ -3332,6 +3332,7 @@
>   pos.mContentOffset = 0;
>   pos.mContentOffsetEnd = 0;
>   pos.mScrollViewStop = PR_FALSE;//dont stop on scrolled views.
>+  pos.mRequireNonPunct = PR_TRUE;

This change concerns me, what if the page contained nothing but punctuation? 
Would it still page up?  Elsewhere the default seems to be "PR_FALSE"

>Index: layout/html/base/src/nsTextTransformer.cpp
>@@ -432,8 +431,17 @@
>     else if (XP_IS_SPACE(ch)) {
>       break;
>     }
>-    else if (sWordSelectStopAtPunctuation && ((readingAlphaNumeric && !isalnum(ch)) || (!readingAlphaNumeric && isalnum(ch)) )) {
>-      // on some platforms, punctuation breaks words too.
>+    else if (sWordSelectStopAtPunctuation && 
>+             readingAlphaNumeric && !isalnum(ch) && isprint(ch)) {
...
>@@ -1092,13 +1104,15 @@
...
>+  PRBool readingAlphaNumeric = isalnum(frag->CharAt(offset - 1));
...
>@@ -1107,9 +1121,20 @@
...
>+    else if (sWordSelectStopAtPunctuation && readingAlphaNumeric && 
>+             !isalnum(ch) && isprint(ch)) {
...

In general (not introduced with your patch), I have a problem with isalnum and
isprint.  I believe (with no hard evidence) that they are the cause of the
problems we have on Macintosh for double-clicking words that contain characters
with diacritics (accents, umlauts, tildes, etc).  For example, on my Mac build,
I get different results when I click between each pair of consecutive
characters for this string:  abcdéfg
clicking btw ab or bc or cd selects:  abcd
clicking btw dé selects: abcdé
clicking btw éf or fg selects:	abcdéfg

Before committing the windows pref change, can you confirm if Windows sees the
behavior I describe above?

Comment 87

[Aaron Leventhal]

Comment on attachment 110258 [details] [diff] [review]
Fixes pref layout.word_select.stop_at_punctuation, selects correct amoiunt of text for ctrl+[shift]+arrow, or double click on word. Needed to add new params to some methods.

Resubmitting for review after answering questions.

>-pref("layout.word_select.stop_at_punctuation", false);
>+pref("layout.word_select.stop_at_punctuation", true);
You shouldn't need to add this in; deletion should be sufficient (since it's in
all.js)
I'm a little wary of making this change but I'd have to check back to the
original bug that caused this pref to be introduced in the first place.

* Windows is not entirely consistent. This fix makes us gives us platform
parity however, by giving us word editing similar to IE's address bar.
* This patch doesn't affect pageup/pagedown.
* I'm using isprint precisely to avoid the innacuracies of isalnum -- because
for the word detection I'm only considering something punctuation if it's not
high bit. That avoids the problem you mention -- stopping at accented letters.
* I can change all the booleans in PeekOffsetStruct to PRPackedBool, if you
think it's better. It would save us 4 bytes of memory -- it might be more work
than it's worth, though -- I'll have to change any methods that pass around
these variables.
* The difference between PR_TRUE or PR_FALSE for the new parameter is whether
we're selecting a word because of a mouse double click or because of keyboard
selection. In the mouse double click (when stop at punct pref is set), it
selects all the letters until the next space or punctuation. Or, if you
double-click on punct, it will select all the punctuation until the next space
or letter. THis is like IE's address bar. For keyboard word selection, it will
select all the letters until the next punctuation or space, then add all the
punctuation or space until the first letter. Hence, it stops at the same place
consistently, like IE, and hence the new PRBool mRequireNonPunct param.

Comment 88

[Aaron Leventhal]

Attachment: Renames mRequireNonPunct to mIsKeyboardSelect, treats high bit chars as alphanumeric so that selection doesn't stop on them

Comment 89

[Aaron Leventhal]

Attachment: Unicode test case. Shows that problems exist with word selection in unicode.

unicodetext[x]-[x]unicodetext
Move by word incorrectly stops before and after the punct

If your pref says stop at punct, it stops twice as much as it should.
If your pref says don't stop at punct, it shouldn't stop at all in those
places.

Comment 90

[Aaron Leventhal]

Spun off bug 188213 for unicode move/select by word issues with punctuation. We
can handle that in a separate patch, so that we don't do too much at once.

Comment 91

[Aaron Leventhal]

Attachment: Now works on mac, after reordering else blocks. Also fixes noisy SelfTest() so it doesn't assert and abort.

Comment 92

[Kathleen :Brade]

Comment on attachment 110965 [details] [diff] [review]
Now works on mac, after reordering else blocks. Also fixes noisy SelfTest() so it doesn't assert and abort.

This line strikes me as wrong:
+    readingAlphaNumeric = isalnum((unsigned char)*cp) || !isprint((unsigned
char)*cp);

it seems like it would set to true if somehow the text contained non-printable
but in ascii range text (control-g/bell?).  Aaron will look at defining
IS_ASCII or similar

Other than that it looks great.

Comment 93

[Aaron Leventhal]

Attachment: Defines IS_ASCII_CHAR(ch) rather than use isprint()

Comment 94

[Kathleen :Brade]

Comment on attachment 110975 [details] [diff] [review]
Defines IS_ASCII_CHAR(ch) rather than use isprint()

r=brade

Comment 95

[Aaron Leventhal]

checked in

Comment 96

[R.K.Aa.]

*** Bug 188484 has been marked as a duplicate of this bug. ***

Comment 97

[Sander]

*** Bug 189741 has been marked as a duplicate of this bug. ***

Comment 98

[Jo Hermans]

*** Bug 189952 has been marked as a duplicate of this bug. ***

Comment 99

[R.K.Aa.]

*** Bug 190375 has been marked as a duplicate of this bug. ***

Comment 100

[Martin Poirier]

*** Bug 192073 has been marked as a duplicate of this bug. ***

Comment 101

[Vaclav Dvorak]

I'm totally confused. AFAICT, this was checked in in time for 1.3b, right? I
finally downloaded 1.3b, and trying the testcase, cases 5 and 6 don't work as
described. Also, bug 125172 is marked FIXED ("fixed via checkin for bug 98546"),
but any word-related action in the URL bar is still totally useless
(ctrl+backspace clears the whole text from cursor to start, double-click selects
all...). I'm talking about Linux here, so I suppose it's because of
layout.word_select.stop_at_punctuation set to false, right? Is this intentional?
Is there UI for the pref?

If it's intentional, shouldn't the URL-bar be a special case? I think that there
normally can't be a space in the URL, so the current behaviour is useless.

Comment 102

[Aaron Leventhal]

Vaclav, there's no UI for the pref. On linux though, I believe the default
should be for word select to stop at punctuation. 

Comment 103

[Vaclav Dvorak]

Aaron, I'm afraid not, see:
http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/unix/unix.js#79
Judging by comment 18, that seems intentional. :-(

Now, should I file a bug requesting a change of this setting for Unix, or a bug
requesting special-casing the URL bar?

Comment 104

[Akkana Peck]

I tried running with the other setting for a while and found it incredibly
frustrating (I kept doubleclicking on urls and pasting something like "www" into
some other window when I expected the whole url).  

I find that unix apps are somewhat inconsistent about this.  But admittedly,
editing apps tend to stop at punctuation by default.  I'd like some feedback
from other users; I found the change so annoying that I really don't want to
flip it without significant feedback saying people want it (not just one
person).  Can you post on mozilla-unix and see if we can get some comments there?

Alternately, if we could get the urlbar special-cased, I'd be quite happy to
flip the default value for the pref, since it's really only in the urlbar that
it's so annoying (but that's a big deal for mozilla).   There's some kind of
special click handler on the urlbar already, isn't there?  Anyone know where
that lives?  Perhaps it would be easy to extend it to check for doubleclick.

Comment 105

[sairuh (rarely reading bugmail)]

could the fix for this be the cause of bug 193776?

Comment 106

[sairuh (rarely reading bugmail)]

ah, looks like bug 193776 is a dup of bug 193689.

Comment 107

[Jeremy M. Dolan]

As for akkana's call for feedback...

I am a UNIX (Linux) user, and the only two apps I really use are rxvt and
Phoenix. I very very very often copy URLs from rxvt (mail, news, irc) with
double-left-click, and single-middle-click to paste into the browser.

The only thing I've changed in my work habits in X in the last 4 years has been
the transition from Netscape 4, to Mozilla, to Phoenix. The following rxvt
resource has, I believe, completed fine tuning and is as efficient as possible
in selecting useful hunks of text out of bigger hunks:

rxvt.cutchars:                  `"'()[]{}<>,;|

Perhaps if context could be taken into account, punctuation followed by
whitespace should be a stop character, but punctuation surrounded by word
characters is quite often part of a URL.

As for behavior in the URL bar, I can't imagine any useful behavior other than
stoping at /'s. And even the usefulness there is debatable. I've seen other
users work and many don't know about ctrl-l/alt-d, so they select the whole URL
with the mouse to type over.

Comment 108

[Vaclav Dvorak]

In the URL bar, you can always select the whole URL by triple-clicking (if
browser.urlbar.clickSelectsAll is false) or just single-clicking (if it's true).
But see also bug 62491 and bug 125172. This isn't the case in normal text
because triple-click selects the whole line which could contain more than what
you want.

I can imagine that people on Unix are used to selecting non-link URL's in web
pages by double-clicking them, so changing the default of
layout.word_select.stop_at_punctuation to true isn't acceptable. But in any
editor (URL bar, but also mail composer...), I believe the situation is
different. You're more likely to _edit_ the URL, for which a word-operation that
acts on the whole URL instead of its parts is useless. And it's not just the
slash that should be the separator - all punctuation should be.
(www.whitehouse.com<Ctrl+Backspace>gov)

So what I'm proposing is this: how about making the stop_at_punctuation apply
only to non-editable controls, and have editable controls act as if
stop_at_punctuation is true? That's actually a new bug, though. Should I file it?

See also bug 16203.

Comment 109

[Alfonso Martinez]

*** Bug 194860 has been marked as a duplicate of this bug. ***

Comment 110

[sairuh (rarely reading bugmail)]

my test results will be posted to http://hopey.mcom.com/tests/bug-98546.html
--will attach it here once i'm done.

Comment 111

[sairuh (rarely reading bugmail)]

Attachment: test results with 2003.03.03 trunk bits

this looks fine. issues i saw have separate bugs.

bug 194322: option-right on mac and control-right on linux stop too much.
bug 195968: option-right delete on mac doesn't work.

Comment 112

[sairuh (rarely reading bugmail)]

and verifying.

Comment 113

[Eyal Lior]

this bug might be marked "VERIFIED FIXED" bug it doesn't work for me. the caret
doesn't stop at any point from left to right. linux, 1.3b. Might be the MultiZilla?

Comment 114

[Vaclav Dvorak]

Eyal: Are you, by any chance, talking about the URL bar, or any other line of
text that contains punctuation but no spaces? If so, then it's because of the
pref layout.word_select.stop_at_punctuation being true by default. If you want
to change it, see bug 193025. And if you want to have the default changed, see
bug 190615.

Comment 115

[Vaclav Dvorak]

*** Bug 192575 has been marked as a duplicate of this bug. ***

Comment 116

[Boris Zbarsky [:bzbarsky]]

*** Bug 196167 has been marked as a duplicate of this bug. ***

Comment 117

[Eyal Lior]

Nope, it's not the layout.word_select.stop_at_punctuation. url bar doesn't
change behavior.

Comment 118

[Vaclav Dvorak]

Eyal: Did you see bug 193025? The pref layout.word_select.stop_at_punctuation
currently can't be set in the user's prefs.js file. If you want to change it,
you have to do it in <moz inst dir>/defaults/pref/unix.js. Does that help?

Comment 119

[Eyal Lior]

Seems to work now. thanx