Split layout.word_select.stop_at_punctuation behaviour in two prefs, one for keyboard, one for mouse

RESOLVED EXPIRED

Status

--
enhancement
RESOLVED EXPIRED
16 years ago
8 years ago

People

(Reporter: svl-bmo, Unassigned)

Tracking

({helpwanted})

Trunk
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
After bug 125172 was fixed (by way of bug 98546) there were several bugs opened
due to how annoying this behaviour is in the URL bar (mostly due to the
triple-clicking now necessary to select the entire line). See for example bug
188567.
Here's another request for a solution, this one proposed by Boris in
http://www.mozillazine.org/forums/viewtopic.php?p=48659#48659
Split the behaviour associated with the layout.word_select.stop_at_punctuation
pref in two, one that affects keyboard-operations (ctrl-arrows), which is
something that (IMO) everyone wants, and one that affects mouse-operations
(clicking/double-clicking/triple-clicking), which a lot of people don't want to
have and should not be related to what happens with keyboard input.

Comment 1

16 years ago
I wouldn't want my double-clicks to select punctuation normally, although I
might want that behaviour for the URL bar. So, I propose a different thing:
split the pref in a general one, and an exception for double-clicks in URL bar
only. Or, to allow for ultimate flexibility, split the pref in four: keyboard in
URL bar, mouse in URL bar, keyboard elsewhere and mouse elsewhere.

"Selection" is probably a more appropriate component for this - CCing the
default owner of that. And setting severity=enhancement.

However, note that the right solution for the problem that you outlined is bug
62491.
Severity: normal → enhancement

Comment 2

16 years ago
Uh... forget that last sentence, that's nonsense. Sorry.

Comment 3

16 years ago
Adding myself to the list.  I'd like to be able to select all text with a
double-click in a text box - just like I can do in the URL with this pref. 
While this is the *original* intent of this bug, comment 2 suggests that the
pref could be broken out to include keyboard/text box behaviour as well.  Rather
than file a new bug with that specically, I'll wait to see how this one goes.

Comment 4

16 years ago
s/is the *original* intent/isn't the *original* intent  (still waiting for bug 540)

Comment 5

16 years ago
IMO WordPerfect does is best (all of Mozilla should be this good & consistent):

1x click - place curser
2x click - select word (the URL is ONE word!)
3x click - select sentence (until period and a space: ". ")
4x click - select an entire paragraph
CTRL-A   - select all text (textbox contents, if it has focus)

And most importantly: The URL is ONE word! 2x click should select entire URL!

PS. Why does the double click select the word PLUS the space behind it? If I
select a word, I almost never want the trailing space. Please don't select the
trailing space.
(Reporter)

Comment 6

16 years ago
Kindly keep this bug free of inane chatter and other proposals. Either take such
talk to the newsgroups or file seperate bugs for it. This one is "as is" - and
should in time be either fixed or wontfixed depending on what happens overall.
Boris proposed what I described in comment 0, I agree that it would be a good
solution, and that is what this bug is about.

Comment 7

16 years ago
So what you're saying is that this bug is ONLY about splitting it into two prefs
and that I should file yet another bug on splitting it into four prefs?  (That
seems awfully redundant / at odds.)
(Reporter)

Comment 8

16 years ago
Sorry, I should have specified my reaction was mostly aimed at comment 5.

Updated

15 years ago
Keywords: helpwanted

Updated

12 years ago
Blocks: 344417
(Assignee)

Updated

10 years ago
Product: Core → SeaMonkey
Assignee: aaronleventhal → nobody
QA Contact: claudius → location-bar

Comment 9

10 years ago
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED

Comment 10

9 years ago
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.