Open
Bug 188567
Opened 22 years ago
Updated 4 years ago
Double-click to right of text should highlight everything.
Categories
(Core :: DOM: Selection, enhancement, P5)
Core
DOM: Selection
Tracking
()
NEW
People
(Reporter: jasonb, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
(deleted),
image/png
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030110 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030110 Now that you have to *triple* click to highlight the URL bar, with the fix for bug 125172, it's incredibly annoying. Double-clicking was far easier. Rather than fight a bug which has just been fixed, I propose that it function just as it does with the exception that double-clicking at the END of the URL (in blank space) function as it did prior to bug 125172. If you want to highlight just the "word" at the end you can double-click directly on it, but clicking to the right of the text, on empty space, should highlight everything. A triple click is something that hardly anybody does and which should be reserved for functions that are very seldom used. I, for one, used to double-click on the URL bar all the time to highlight it all and do not believe it's so rare a browsing habit as to warrant relegating it to such an uncomfortable mouse maneouver. (I'd be happy with a double-click at the end.) I would actually consider it to be a regression in the browser that there's now no easy way of highlighting the entire URL text with the mouse. Reproducible: Always Steps to Reproduce: 1. Double-click the URL bar to the right of existing text. Actual Results: Last "word" is highlighted. Expected Results: Entire URL text should be highlighted.
Reporter | ||
Updated•22 years ago
|
Keywords: regression
Comment 1•22 years ago
|
||
Agreed. It's very annoying to have to triple-click now. And I know people who have trouble with double-clicking, let alone triple-clicking. Also, I just tried out IE, and IE double-clicks to select words, triple-clicks to select all the text, but only in normal text fields. In IE's URL bar, double-click selects all the contents.
Reporter | ||
Comment 2•22 years ago
|
||
> In IE's URL bar, double-click selects all the contents.
Really? For me, using IE 6 (latest fixes <grin>) I only need to do a *single*
click to highlight everything. That may be overkill (I think that double-click
is more appropriate), but it's still dramatically better than triple-click.
Comment 3•22 years ago
|
||
There is a preference to cause Mozilla to select the entire URL on a single click. I believe that it is on by default for windows. This was partially broken by a Mac fix for bug 116441 which is currently being corrected. Any changes should only be made with full knowledge of the existing (and almost-existing) preferences and required multi-platform behaviour. Given that there is an easy (one click) way of selecting the entire URL and this should be the default behaviour for windows, I don't think any change is needed other than the fix described in bug 116441 comment 21.
Reporter | ||
Comment 4•22 years ago
|
||
I said that a single click was better than a triple click - I didn't say that it was acceptable. I currently DO have the pref in place to not select the entire text with a single click. With a single click, I want to highlight only what I select for copy /paste. There still needs to be some way of getting what we had before without also doing away with a simple select copy/paste procedure.
I like the suggestion of Jason: a double click in the empty space of a text box (URL or other) should select the whole content. Currently when you double-click in a text box (try the Summary line above), it selects the 'nearest' word (the one at the end). I believe it should select the content of the whole box, because that's what you mean: you click on the content and double click, thus you want all the content... Doesn't it sound logical? At least it does to me :-) BTW, I like the new behaviour for the URL, I very often change only 'one word' in the URL line on my corporate website to get quicker access and previously it was painful...
I think clicking _next_ to the url and clicking _on_ the url should behave exactly the same. If I want to edit the url, I never click on it, because then the mousecursor obscures part of the text I'll be typing. Yet sometimes you're dealing with these incredibly long urls that prevent you from clicking next to them. And I for one _don't_ want to have a mental model of the differences between clicking on and clicking next to. If I have to think about what happens when clicking on the url bar, that slows me down and I'd rather not click anymore at all... Then from there on there are three options for how to proceed that might make sense depending on the single pref we have to influence behaviour. 1) - single click selects the entire line if "ClickSelectsAll" is set, or only places focus if it isn't. - double-click in both instances selects one word (current behaviour) - triple-click in both instances selects the entire line (current behaviour) or probably more logical as it 'shifts' the entire cycle dependent only on the one "ClickSelectsAll" pref: 2) - single click selects entire line if "ClickSelectsAll" is set, or only placing focus if it isn't. - double-click focuses if "ClickSelectsAll" is set, or selects one word if it isn't set. - triple-click selects one word if "ClickSelectsAll" is set, or the entire line if it isn't set. or, seeing how no one seems to like selecting just one word: 3) - single click selects entire line if "ClickSelectsAll" is set, or only placing focus if it isn't. - double-click focuses if "ClickSelectsAll" is set, or selects the entire line if it isn't set. - triple-click in both instances selects one word. Options 2 and 3 are my favorites. As far as I understand bug 116441, that the click after the url no longer doing the same as clicking on the url is a regression on windows, caused by mac behaviour, and will be patched when the proper fix for that bug is checked in. In 1.2.1 at least clicking after the url and clickiong on the url did exactly the same on windows.
Reporter | ||
Comment 8•22 years ago
|
||
> a double click in the empty space of a text box (URL or other) should
> select the whole content.
Great idea! I'd only been thinking about URLs, but I do, on a daily basis, have
to select entire lines of textboxes (to report daily bug fixes to MozillaZine
based on bug Summaries) and it would be VERY useful if I could also quickly
select the entire Summary line without having to triple-click it too.
Reporter | ||
Comment 9•22 years ago
|
||
> If I want to edit the url, I never click on it, because then > the mousecursor obscures part of the text I'll be typing. We're talking about a double-click here. A single-click to the right of the text, as you're used to, would still let you edit properly as you already do. > Yet sometimes you're dealing with these incredibly long urls We'd just have to live with that. I don't find it all THAT common and I can do a triple-click if I have to in those circumstances. (Or, alternatively, we could leave a few characters of white space between the end of the URL text and the URL history down arrow, that never gets used, so that there is always something to double-click on.)
Comment 10•22 years ago
|
||
I support item 2 in comment 7 (and item 3 might prove even better) - with click selects all set the behaviour should be as for a normal text bok *but* with an offset since the first click is anomolous. This is also the behaviour advocated in bug 62491. Current (or even position dependent) behaviour might be acceptable in the case where click selects all is false. Howevr behaviour that depends on url length seems unintuitive to me (user naturally always double clicks to right of url to highlight everything - finds site that has a long url and tries to select everything - find they are selecting some irrelevant subset of the url). Also note that, at present when click to select is set, a single click to the right does not highlight everything, only focuses.
Reporter | ||
Comment 11•22 years ago
|
||
> Current (or even position dependent) behaviour might be acceptable > in the case where click selects all is false. Perhaps I should have explicitly stated that this bug is relavent only in the case where "selects all" is false via the preference. I assumed that it would be implicitly acknowledged given that if you DO already have it set to true then you wouldn't be bother by the sudden lack of the old double-click behaviour. > Howevr behaviour that depends on url length seems unintuitive to me Read the 2nd half of comment 9 again. > Also note that, at present when click to select is set, a single click > to the right does not highlight everything, only focuses. That should be discussed in a different bug. (Although if this get implemented it would be the perfect complement to the "reverse" behaviour of setting the preference the other way.)
Comment 12•22 years ago
|
||
Is everyone in this bug someone who edited their user.js file and changed either user_pref("layout.word_select.stop_at_punctuation", true/false); or user_pref("browser.urlbar.clickSelectsAll", true/false); Unix is the only platform where clickSelectsAll is false by default. However, we also have word_select.stop_at_punctuation set to false by default on Unix. So, unless you are changing your default prefs, there is no problem. **** Solutions **** 1. You can set user_pref("layout.word_select.stop_at_punctuation", false); to get your old behavior back. or 2. Since you're about to start typing in the URL bar anyway, why not use the keyboard to select the URL. That avoids having to go to the mouse at all. To select the URL, you can type either accel+L or Alt+D (as long as you're not in a page that uses D as an accesskey, like this bugzilla page). -> Nobody. If neither of those solutions are good enough, someone else can take this bug. We're currently exhibiting the corret behavior on single/double/triple click.
Assignee: aaronl → nobody
Reporter | ||
Comment 13•22 years ago
|
||
> You can set user_pref("layout.word_select.stop_at_punctuation", false); > to get your old behavior back. Confirmed. This "negates" the effects of contributing bug 98546 and the entire text is, once again, selected as before. Removing "regression" keyword since it's possible to restore old behaviour by setting this preference. However, I still think that it would be useful to have the following situation: Single-click = cursor insertion Double-click = highlight word (stopping at punctuation) Triple-click = highlight entire URL Double-click to right of URL text = highlight entire URL I don't see any way of doing that with the current prefs.
Severity: normal → enhancement
Keywords: regression
Comment 14•22 years ago
|
||
I agree with comment 13. I'll post about this feature to some russian forums and we'll see what people think about it.
Reporter | ||
Comment 15•22 years ago
|
||
Oh, and this should also apply to regular textboxes as per comment 6 - something which user_pref("layout.word_select.stop_at_punctuation", false); does not modify, since spaces are not considered punctuation but "word breaks". I agree with that, but it means that there's no workaround for the textbox scenario. (I know that they've behaved that way for much longer.)
Reporter | ||
Comment 16•22 years ago
|
||
As of the 20030114+ builds, I can't get user_pref("layout.word_select.stop_at_punctuation", false); to work. Double-click, once again, selects only a single word. Is anyone aware of something that was checked in that broke this pref?
Comment 17•22 years ago
|
||
Nominating for nsbeta, since the feedback is very negative on the new tripple clicking feature.
Keywords: nsbeta1
Comment 18•22 years ago
|
||
I don't get it... are you all gone mad here ? The default behaviour is to select the entire address bar with a SINGLE click, which is obviously easier than a double click. The triple-clicking feature is a plus in case you double-click by mistake, but you will be used to it in a few days (hours?)
Reporter | ||
Comment 19•22 years ago
|
||
First of all, you cannot single click on the URL to the right of the text and have it highlight everything. Instead, the cursor is put at the end of the URL text. This behaviour is specified by bug 116441. So being able to double-click at the end of the URL and have it select everything is functionlity that does not currently exist with ANY pref in use. Secondly, see comment 13.
Comment 20•22 years ago
|
||
Confirming comment #16, user_pref("layout.word_select.stop_at_punctuation", false); does not work on Mozilla 1.3b for Win2K. There is no way to restore the old behavior.
Comment 21•22 years ago
|
||
From a purely USER standpoint; the triple-click is an annoyance. When I first encountered it, I personally thought it was an annoying bug and didnt realize it was by design. I dont normally triple-click for anything, certainly not something as common as the entire url highlight in the browser url box. I would like to just add a comment in support of the removal of this "feature", and make double-click a simple highlight of the entire url. I suppose a single-click would just insert the cursor where you clicked.
Comment 22•22 years ago
|
||
I whole-heartedly support dumping the rediculous tripple click to select the whole URL bar. This is NOT paragraph text! After spending several days "attempting" to tripple click the URL bar in Moz 1.3b, I'm dumping Mozilla. This is the most annoying behaviour I've ever run across! I suspect due to lack of man-power, they've just applied all text editing/selecting prefs to the whole page, URL and all. BIG mistake, folks. You're going to lose users over this one. No one in their right mind would be tripple clicking a URL to select the whole thing. I've been using PC's since their inseption and can honestly say I've never had to tripple click ANYthing for ANY reason, and I ain't going to start now. OK, how's this: Double click IN the URL selects a word. Tripple click IN the URL selects the whole thing (If you've got to have it that way). Double click to the right of the URL selects the whole thing. Believe me, tripple clicking is a joke and should be shunned for all eternity.
Comment 23•22 years ago
|
||
I'm another user who has been annoyed lately by the sudden increase in difficulty in selecting the entire contents of the address bar, which I do regularly both in order to type a new URL in place of the old one, and to copy the current URL to paste into another document or Web form field.
Comment 24•22 years ago
|
||
The problem with this bug is that many URLs are very long. Thus the right end of the URL is not going to be visible. Therefore, this bug will not solve the problem for many users (low res) and/or situations (long URLs). Suggest WONTFIX, and to back out the poor choice tripple clicking sillyess.
Comment 25•22 years ago
|
||
This is horrible! How often is selecting a "word" in the URL bar needed anyway? I bet it's much more frequent to want to select the whole URL... One thing that has not been mentioned is that more often than not, the last "word" selected will just be the slash at the end of the site name. For example: 1. Enter "bugzilla.mozilla.org" in the URL bar and press enter. 2. Bugzilla loads and the URL bar changes to "http://bugzilla.mozilla.org/". 3. Double-click to left of URL bar. 4. "/" is selected. This is clearly useless.
Reporter | ||
Comment 26•22 years ago
|
||
> Thus the right end of the URL is not going to be visible. Already addressed in the second paragraph of comment 9. It would be quite easy to leave a small margin of white space between the end of the URL text and the history arrow.
Comment 27•22 years ago
|
||
The requested behaviour would be totally inconsistent with the rest of your computer. When you double-click in the empty space after the end of the line anywhere in Windows, the last word is selected, and that's what I expect. Instead of debating here, I recommend that you focus your attention at bug 193025 (comment 16 in this bug), or learn to use the keyboard (Ctrl+L, Alt+D). Also, bug 16203 might help you in your suffering. ;-)
Reporter | ||
Comment 28•22 years ago
|
||
> The requested behaviour would be totally inconsistent with the rest of > your computer. On the contrary. The closest "comparison" we can make is to another Windows URL bar (which is not the same as normal fields). In such a case, we'd be talking about IE. In IE, any number of clicks (including double-click to the right of the URL text) selects the whole thing. > I recommend that you focus your attention at bug 193025 I'm the person who filed that bug. <grin> I'll accept it as better than what we have now, but fixing THIS bug is still what I'd prefer. (Actually, I'd prefer banishing the entire triple-click behaviour altogether and going back to what it was prior to bug 125172 - but there's no point in arguing for that here in this bug.) > Also, bug 16203 might help you in your suffering. ;-) How convoluted. <grin> Bottom line here - I want to easily select the entire URL with the mouse, not have to jump through hoops to get to that state.
Comment 29•22 years ago
|
||
> > The requested behaviour would be totally inconsistent with the rest of > > your computer. > On the contrary. The closest "comparison" we can make is to another Windows > URL bar (which is not the same as normal fields). In such a case, we'd be > talking about IE. In IE, any number of clicks (including double-click to > the right of the URL text) selects the whole thing. Uh... yeah, you're actually right - IE is that much broken: although it does handle individual parts of the URL as "words" WRT keyboard navigation (Ctrl+left/right, Ctrl+Shift+left/right), it does not do so for the mouse. Also, it makes you do a triple-click (or two clicks separated by a delay) just to place the cursor in the line. You would want that? I hope not. IE's double-click behaviour is redundant, because there you can use just a single-click to select the whole URL. So, if you want to use IE-parity as an argument, then your comment 13 is invalid. You contradict yourself. :-) Note that I'm talking about IE 5.5, with default settings (if it has any relevant settings, which I'm not aware of). I suppose 5.0 and 6.0 are the same in this respect - am I wrong? I want to be able to double-click after the end of http://www.whitehouse.gov/ and type "com" and Enter and get to the right place. ;-)
Comment 30•22 years ago
|
||
> Also, it makes you do a triple-click (or two clicks separated by
> a delay) just to place the cursor in the line. You would want that?
Hello? You do realize, don't you, that since 1.3b this is the default behaviour
of Mozilla under Windows? To place the cursor in the URL bar you have to click,
wait, and then click again. And it is horrible. :-(
Comment 31•22 years ago
|
||
> > Also, it makes you do a triple-click (or two clicks separated by > > a delay) just to place the cursor in the line. You would want that? > Hello? You do realize, don't you, that since 1.3b this is the default > behaviour of Mozilla under Windows? To place the cursor in the URL bar > you have to click, wait, and then click again. And it is horrible. :-( Sure. But that's a completely different bug: bug 62491. You yourself have commented there, and I agree with that comment. That bug should be fixed.
Comment 32•22 years ago
|
||
Lorenzo Colitti (comment 30)--that actually is not a regression from 1.2. In my experience I see that behavior long before mozilla 1.0 (see bug # in comment 31)
Reporter | ||
Comment 33•22 years ago
|
||
> So, if you want to use IE-parity as an argument In no way. <shudder> In point of fact, comparing what Mozilla should do with the way something else does it is a poor argument. The only good it serves is to give an example. > I want to be able to double-click after the end of > http://www.whitehouse.gov/ and type "com" and Enter and get to the right > place. ;-) This bug wouldn't prevent what you want to do at all. Just double-click on "gov", type "com", and hit Enter. Of course, you need to double-click on the "word" you want to replace, not at the end of the text, but why do you need to double-click at the end anyway? > To place the cursor in the URL bar you have to click, wait, and then > click again. Just change the default behaviour with the following modification: user_pref("browser.urlbar.clickSelectsAll", false); Now a single click will put the cursor into the URL without selecting it. The point here is that there should be an easy way of getting the kind of URL selection you'd like without resorting to a series of circus contortions (triple click). Since we have only two different (non-triple click) methods of selecting text (single-click and double-click) but have *3* different things we want to accomplish (cursor insertion, "word" selection, and entire URL highlighting) the only way of accomplishing it is if we modify the action of one of those two types of clicks in certain circumstances. So far the only real argument I've seen against a double-click at the end of the URL text is at the end of comment 29 - but I'm not sure I see why a double-click on the "word" being replaced wouldn't be sufficient.
Comment 34•22 years ago
|
||
> > So, if you want to use IE-parity as an argument > In no way. <shudder> In point of fact, comparing what Mozilla should do > with the way something else does it is a poor argument. The only good > it serves is to give an example. Actually, it's generally a pretty good argument. We don't want to invent new behaviours for everything - rather, we want to behave so as to conform with what the user is used to. Unless, of couse, such behaviour would be completely broken, useless or even counter-productive, which would be the case with emulating IE's URL-bar mouse-click reactions. :-) > > I want to be able to double-click after the end of > > http://www.whitehouse.gov/ and type "com" and Enter and get to the right > > place. ;-) > This bug wouldn't prevent what you want to do at all. Just double-click > on "gov", type "com", and hit Enter. Of course, you need to double-click > on the "word" you want to replace, not at the end of the text, but why do > you need to double-click at the end anyway? Well, when I'm selecting the last word, I'm used to having the possibility to double-click anywhere in _or_after_ it, because it works that way everywhere else. But OK, there's many of you. Let's do what you want, but make it a hidden pref, off by default. All of you who want this must have tweaked your prefs already, anyway, because otherwise you could just single-click (or double-click anywhere, if you use Unix).
Comment 35•22 years ago
|
||
Would most of you be satisfied by bug 52784? That seems like a better solution to me...
Reporter | ||
Comment 36•22 years ago
|
||
No - that also doesn't address the possibility of double-clicking to the right of text box text to selected everything there too, as suggested in earlier comments here.
Comment 37•22 years ago
|
||
I know it doesn't, but I thought that this bug was about having an easy way to select the whole URL with clickSelectsAll=false and stop_at_punctuation=true... If you want the requested behaviour to apply to all text and not just the URL bar, then the Component should be changed to Selection. But, as I said before, that behaviour would be inconsistent with the rest of the computer. And it would be very irritating at least for me. (And if you want it to apply only to "text box text" and not, for example, normal text on web pages, then Mozilla would be inconsistent even with itself.)
Comment 38•22 years ago
|
||
Clickking once *outside* the text once in WordPerfect selects the whole sentence nearest the click. Of all the text selection fuctionalities, WordPerfect by FAR does it best of ALL programs (incl Word and Mozilla): Click *inside* text: 1x - places curser 2x - selects word 3x - selects sentence 4x - selects paragraph PS. The URL should be treated as a single word (2x clicks selects entire URL)!
Reporter | ||
Comment 39•22 years ago
|
||
-> Should be Selection anyway, now that I think of it. > And it would be very irritating at least for me. Not with the addition of bug 194925.
Component: URL Bar → Selection
Reporter | ||
Comment 40•22 years ago
|
||
> Clickking once *outside* the text once in WordPerfect selects the whole > sentence nearest the click. FWIW: MSWord also behaves the same way. Also, my "programmers" text editor, Text Pad (http://www.textpad.com/) does an insert on a single click, highlight word on double-click, highlight everything on triple-click - and hightlight everything on double-click OUTSIDE of the text in the margin.
Updated•22 years ago
|
OS: Windows XP → All
Hardware: PC → All
Summary: Double-click to right of URL bar text should highlight everything. → Double-click to right of text should highlight everything.
Reporter | ||
Comment 41•22 years ago
|
||
*** Bug 196547 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 42•22 years ago
|
||
*** Bug 196566 has been marked as a duplicate of this bug. ***
Comment 43•22 years ago
|
||
*** Bug 196685 has been marked as a duplicate of this bug. ***
Comment 44•22 years ago
|
||
*** Bug 197560 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 45•22 years ago
|
||
I thought I'd mention that you can now click on the proxy icon to the left of the URL text to highlight everything, thanks to the fix for bug 52784. This certainly makes life simpler, but I'd still like to see double-click to the right implemented (it's a bit tricky to quickly "zero in" on the proxy icon).
Reporter | ||
Comment 46•22 years ago
|
||
*** Bug 200319 has been marked as a duplicate of this bug. ***
Comment 47•22 years ago
|
||
I was just told about: user_pref("layout.word_select.stop_at_punctuation", false);
Reporter | ||
Comment 48•22 years ago
|
||
That preference is broken - you can't use it in prefs.js or user.js. It only works if you add it to all.js, but that will be overwritten everytime you upgrade to a more recent build. (Which I do at least once a day, so, for me, it's not a usable workaround.) While I'm here, I'll add a dependency to bug 193025 since, if it's fixed, we'll again have a usable workaround while we wait for a real fix.
Depends on: 193025
Comment 50•21 years ago
|
||
As primarily a Windows user, I don't care whether a single-click or a double-click selects the URL line, since IE will do it either way, but please make the behavior consistent, whether the user clicks within the text or to the right of the text. The 'long URL' and 'low resolution' problems make doing it any other way a kludge, at best. I understand that normally single-click should place the caret and double-click should select the nearest word in a regular text box, but the location bar is not a regular text box, and we're not writing an essay here. Generally speaking, a URL is one 'word' and should be treated as such. Either way is fine, but make the blank space behave the same. If a triple-click was intended to be part of the UI design for Windows, there would be a TripleClick() event on standard Windows text boxes. There isn't. If you'd rather treat each part of the URL as a 'word', then make single-click select all and double-click select 'words'. For those who just want to insert something into a URL, double-click left arrow would be better than the current behavior. Use triple-click for the other platforms if you want, or make it a preference. Defaulting it to OFF would be greatly appreciated on Windows, however. You will lose users over this one. It's just too annoying as-is (in 1.3.1). If it were up to me, I'd up the severity on this one. However, it's the only real problem I'm currently having with Mozilla, which is good. :) I consider this a regression, though.
Reporter | ||
Comment 51•21 years ago
|
||
As of the 2/26 build under XP I just noticed that double-clicking the URL selects everything. Something has changed at some point. Either the double-clicking behaviour has changed - or bug 193025 has been corrected. Can anybody else confirm this and point to what's been fixed, how, and when?
Reporter | ||
Comment 52•21 years ago
|
||
I just double-checked, and this is not because bug 193025 has been resolved. (I changed "layout.word_select.stop_at_punctuation" to true - and double-clicking still highlighted everything.) I'll give everybody another couple of days to let me know if this is still not working for you - then, if I don't hear anything to the contrary, I'm going to remove the dependency and mark this bug as WORSKFORME. (I have the feeling that I've subconsciously been noting this working for a while now, but have just never actively twigged to it.)
Comment 53•21 years ago
|
||
I am using 1.6 under XP, and it does not work for me. Double clicking only selects whatever is after the last punctuation mark (so when looking at this bug, double clicking to the right stops at the equals sign, highlighting "188567" but not "http://bugzilla.mozilla.org/show_bug.cgi?id=")
Comment 55•4 years ago
|
||
Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.
If you have reason to believe this is wrong, please write a comment and ni :jstutte.
Severity: normal → S4
Priority: -- → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•