Closed
Bug 62491
Opened 24 years ago
Closed 15 years ago
[clickSelectsAll] Double-click in location bar should focus without selecting
Categories
(SeaMonkey :: Location Bar, defect)
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: jruderman, Unassigned)
References
Details
(Keywords: platform-parity)
No description provided.
Reporter | ||
Comment 1•24 years ago
|
||
Triple-clicking in the location bar should put the insertion point where you clicked instead of selecting the entire url, because otherwise clearing the selection can be frustrating. (Bug 53485 also helps make it frustrating.) I can think of two ways to do this that would be somewhat more general, but neither is perfect. - Mark the location bar as a "single-word" textbox, which would make triple-clicks clear the selection, make pastes including \n's strip the \n's instead of converting them to spaces, etc. (Are there other "single-word" textboxes?) - Make the triple-click code check whether there are multiple words. If there are multiple words, select all of them; if there aren't, clear the selection and put the insertion point in the right place. (This could be confusing if you're not sure ahead of time whether a large block of text contains spaces.)
Reporter | ||
Updated•24 years ago
|
Summary: Triple-click in location bar should act like single click instead of selecting all text → Triple-click in location bar should act like single click (instead of selecting all text)
Comment 2•24 years ago
|
||
On Unix, triple click means select line, and changing that would cause frustration for many users. But I agree that the current setup is probably frustrating for Windows users who are used to clickSelectsAll. I suggest that triple-click should be changed to set the caret, but not select the line, only when clickSelectsAll is set (which may soon become the default setting on Windows). I think Anthony has the clickSelectsAll bug -- cc'ing.
Severity: minor → normal
Status: NEW → ASSIGNED
Keywords: correctness
Target Milestone: --- → mozilla0.9
Comment 5•24 years ago
|
||
It seems to me (maybe I'm wrong?) that the urlbar should be able to fix this if so desired (check the clickCount and handle the event if appropriate) Reassign to XPApps. If we decide that the correct fix is in selection, reassign the bug back to anthonyd.
Assignee: anthonyd → blakeross
Status: ASSIGNED → NEW
Component: Editor → XP Apps: GUI Features
Keywords: pp
QA Contact: sujay → sairuh
Target Milestone: mozilla0.9.1 → ---
Comment 6•24 years ago
|
||
Umm....I don't want to special case the urlbar more than is necessary. I'd prefer that this be a basic behavior of all textfields if we're going to do this. Also, it seems like we're going to do click-selects-all in the urlbar, at least for some platforms. -> UI Design to sort all this out
Assignee: blakeross → mpt
Component: XP Apps: GUI Features → User Interface Design
QA Contact: sairuh → zach
Comment 7•24 years ago
|
||
For ordinary text fields: * a single click should place the caret; * a double click should select the `word' surrounding the click position (e.g. double-clicking on the `w' of http://bugzilla.mozilla.org/show_bug.cgi?id=62491' would select `show'); * a triple click should select the entire field contents; * a quadruple click or beyond should continue this cycle. For the address field, if it is set to click-to-select: * a single click should select the entire field contents; * a double click should place the caret; * a triple click should select the `word' surrounding the click position; * a quadruple click or beyond should continue this cycle. For the address field, if it is set to click-to-place-caret, like ordinary text fields, then it should behave like ordinary text fields as described above.
Assignee: mpt → blakeross
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → sairuh
Comment 8•24 years ago
|
||
--> URL Bar
Assignee: blake → alecf
Component: XP Apps: GUI Features → URL Bar
QA Contact: sairuh → claudius
Reporter | ||
Comment 9•24 years ago
|
||
Changing summary from "triple-click in location bar should act like single click [focus without selecting]" to "double-click in location bar should focus without selecting" to match mpt's comments in this bug. mpt, by "a quadruple click or beyond should continue this cycle", did you mean cycle from step 1, so that quadruple-clicking in any text field would be the same as single-clicking? Wordpad and Mozilla currently treat quadruple-clicking like double-clicking for ordinary text fields. Are you saying that should change?
Summary: Triple-click in location bar should act like single click (instead of selecting all text) → [clickSelectsAll] Double-click in location bar should focus without selecting
Comment 10•24 years ago
|
||
Actually, Mozilla currently (build 2001071309) ignores quadruple or further clicks completely. Here's my 2001-04-23 suggestion presented in possibly a clearer manner: Number of rapid consecutive clicks Normal text fields Address field with clickSelectsAll ---------------------------------------------------------------------------- 1 Place caret Select paragraph 2 Select `word' Place caret 3 Select paragraph Select `word' 4 Place caret Select paragraph 5 Select `word' Place caret 6 Select paragraph Select `word' 7 ... ...
Comment 12•23 years ago
|
||
as I see nothing has been done to reflect end user feedbacks for this bug, I remove my vote since it is nothing more than a e-mail subscription for me.
Comment 13•23 years ago
|
||
Joe was dying to have these bugs. Who am I to say no?
Assignee: blakeross → hewitt
Updated•23 years ago
|
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 14•23 years ago
|
||
Filed bug 125172 for consistent behavior in all text fields (according to comment 10), *even the URL bar*.
Comment 15•23 years ago
|
||
When the location is unfocoused partial selection of the contents requieres 3 clicks before it begins to select the proper text.
Comment 16•22 years ago
|
||
This bug has been completely superceded by later changes. I suggest that it is closed. In particular, see bug 125172, bug 116441, and bug 188567.
Reporter | ||
Comment 17•22 years ago
|
||
ian@powerpoint-it.co.uk: bug 125172 is about when clickSelectsAll is off, and bug 116441 and bug 188567 are both about what happens when you click in the empty space to the right of the URL in the address bar. I don't see how this bug could be "superceded" by them.
Comment 18•22 years ago
|
||
The fix for bug 125172 quite deliberately set the behaviour for double-clicks in the location bar to select one word, and triple-cliks to select the whole line, whether clickSelectsAll is on or off. This was done after a great deal of discussion and I cannot imagine it changing again to reflect the behaviour requested in this bug. At the very least, the people who made the decisions in bug 125172 would need to be aware that this bug was going to override them. Click through to bug 98546 to see some more discussion and the actual patch for this fix. Bug 116441 is actually about Mac-specific behaviour, but contains interesting information about how this clicking should work on Macs, and some ongoing work to control platform differences when clicking beyond the end of the URL with clickSelectAll on. This would have to be taken into account before changing triple-click behaviour. Bug 188567 is basically requesting a workaround for people who don't like having to triple-click to select the whole URL (following the fix for bug 125172). I mention it because those people are really wanting the same behaviour you request here: double-click selects the whole URL and triple-click goes back to inserting the caret. Anyway, my point is: this bug can no longer be fixed without breaking other bugs that were raised after this one. That is why I used the word superceded. I'm just trying to bring things up to date here so that this doesn't sit around for another two years assigned but not going anywhere.
Reporter | ||
Comment 19•22 years ago
|
||
>The fix for bug 125172 quite deliberately set the behaviour for double-clicks in >the location bar to select one word, and triple-cliks to select the whole line, >whether clickSelectsAll is on or off. Bug 125172 is only about the case when clickSelectsAll is off. There was no "fix for 125172"; it was fixed as a side-effect of the fix for bug 98546. Nor was there any real discussion or decision-making in bug 125172. >Click through to bug 98546 to see some more discussion and the actual patch for >this fix. I can't find the discussion about how double-clicking in an unfocused address bar should work in bug 98546. I tried searching for "address" and "url". (When you refer to comments in other bugs rather than other bugs as a whole, as you did with bug 98546 and bug 116441, please include comment numbers. Bugzilla will create a link to a specific comment if you say "bug x comment y".)
Comment 20•22 years ago
|
||
Excuse me for butting in at this late stage, but when I saw this I couldn't believe my eyes. I just moved from 1.3a to 1.3b on Windows and realized that to place the caret in the location bar (which is possibly the most frequent operation that involves the location bar) now requires two separate single clicks. This is because if clickSelectAll is on (e.g. by default on Windows), a single click selects the whole URL, a double click selects a "word", a triple click selects the URL again, etc. So if you merely want to place the caret in the location bar you have to click (URL is selected), WAIT, and click again. For me, this is horrible. I don't want to have to wait to be able to edit the current URL! If I want to select a word, I can always click and drag... I think that most people will agree with me in saying that simply placing the caret in the URL bar is much more frequent than wanting to select a word in the URL, and so should be easier and quicker. So, could we make it so that double-clicks should only select words if clickSelectAll is off? Then with clickSelectAll on, we could have: - single click selects - double click places caret - triple click selects word (if you like) - successive clicks toggle between word and URL (if you like) As reported in bug 188567 comment #20, setting layout.word_select.stop_at_punctuation to false doesn't solve the problem. A double click still selects the word.
Comment 21•22 years ago
|
||
I don't think this is an enhancement - it's a genuine bug, though perhaps of minor severity according to the definition ("easy workaround is present" - click, wait, click). Comment 10 is nearly right, except that you should probably substitute "line" for "paragraph", because that's what triple-click currently selects in text, and except that quadruple and further clicks are not ignored anymore (but who cares). Changing severity and also resetting milestone, because this bug has recently been made more visible (see bug 188567 comment 30). Nominating for nsbeta1.
Comment 22•22 years ago
|
||
I do agree with all Lorenzo said. Under windows (all version), the standart behaviour is the one he explained : - first clic : select the whole line - second clic : place the caret - third clic : select the word you're on Current behaviour is very weird, and very time consuming : sometimes, you have to clic a lot to be able to place the caret...which is such a common operation. The two things you do the more with an adress bar in a browser are : - changing the whole url to type a new one - modifying an existing one up to a reasonnable extend that include inserting the caret and deleting a large part of the url to rewrite it I would even say that with the tab function, you modify more than you change completely (it's easier to make a CTRL+T to have a fresh adress bar, plus, you don't loose the previous windows) So I do think the current order is irrelevant (PS : this behaviour is anoying at least since the 1.3a, and is still the same in 1.3b and 1.4a) PPS : change OS to all, because it concernes at least all windows version, and acording to comments, this is implement the same way regardless the OS
Comment 23•22 years ago
|
||
Build 20030228 (1.4a) There are several issues in this build Current behavior as I notice: - singleclick on the actual address selects all (set in pref) -> this is ok - singleclick next to address in an empty part sets caret on the end - doubleclick selects 'word' - [problem] tripleclick does nothing [problem] After this, there is no way to get the entire url selected except for moving focus out of the URL bar and back . [problem] Single click on a completely selected url or a selected word does nothing. Under Windows, common is to deselect and set the insertion point. [problem] When moving focus to a different app, than setting focus back by clicking in the address bar sets focus to the address bar, but doesn't repaint the window, so the other app is still on top. 'Singleclick on selection' seems to be a problem in all text fields - is that a seperate bug or does it belong here?
Comment 24•22 years ago
|
||
Anca: "singleclick next to address in an empty part sets caret on the end" is bug 116441, and "tripleclick does nothing" is bug 194710. When describing behaviour of URL bar, please do always explicitly say whether the URL bar was already focused when you clicked, because the behaviour partly depends on that.
Comment 26•22 years ago
|
||
I just installed 1.3 and noticed an incredibly annoying problem with the address bar that may be related to this bug. In all prior version of Mozilla I could double click the address bar (when it was not previously focused) and the entire URL would then be highlighted, allowing me to easily type in a new URL. On 1.3, the first time I double click on the address bar does nothing but focus it, a second double click highlights only some random part of the URL, usually just the trailing slash, and, even if I directly double click over the portion of the address bar containing the URL, only a small piece of it is highlighted such as the tld or hostname. The only way I can find to highlight the whole thing is to manually drag the mouse across it.
Comment 27•22 years ago
|
||
srainwater: What operating system are you using, and did you make any changes to the default prefs? The defaults are: On Windows, single click selects all text. In current builds, this is true whether or not you click after the text; in 1.3, you must click _on_ the text (bug 116441 - didn't land in time for 1.3). Double-click selects a word, triple-click selects all text. This bug is essentially about making an exception from double-click in the case when the URL bar was not focused at the time of the first click. On Unix, single click places caret, double click selects all. This bug doesn't apply. On Mac, single click selects all, except when the click was after the text's end. Double click selects word, triple click selects all. This bug does apply. There is also a bug to let you click on the bookmark/page icon (left of URL bar text) to select all text. And another, to let you select all by double-clicking in the empty space after the end of the text in the URL bar.
Comment 28•22 years ago
|
||
Basically what I would like to see is consistency across the platforms. I use the Windows and the Solaris versions consistently and its a pain having the double-clicks in the location bar do behave differently. I personally don't care which way it works as long as it works the same way on all the platforms.
Comment 29•22 years ago
|
||
William: There are two orthogonal points of view on consistency: 1) Consistency across all applications on one platform. 2) Consistency of an application across all platforms. Obviously, most applications, including Mozilla, are developed with the first concern in mind, because most users only use one platform (rather than one application on multiple platforms) and want to have consistent behaviour. However, with Mozilla, you _can_ achieve virtually identical behaviour on all platforms, simply by adjusting the preferences. Just copy unix.js from you UNIX Mozilla installation directory over win.js in your Windows Mozilla installation directory, and you have UNIX-Mozilla behaviour in Windows-Mozilla. Of course, you can also tune the individual settings in prefs.js in your profile. (But be aware of bug 193025.)
Comment 30•22 years ago
|
||
Turns out the setting can be altered in the all.js file not in the win.js or winprefs.js file. It is easier to make the Unix side look more like the Windows side BTW.
Comment 31•22 years ago
|
||
With all this varying discussion, I'm confused as to what direction this bug is going. The URL/Location should work differently than a regular text field because it is used differently than a regular text field. My personal preference is IE's behavior, which can be described as follows: 1. When window receives focus, the location bar is highlighted. Or, when the location bar receives focus, it get's highlighted. 2. Subsequent behaviour is as follows: A. Single click places the cursor wherever you clicked (whether inside text or to the right). B. Double click highlights entire URL (whether inside text or to the left). C. When the user drags, the cursor is placed and dragging allows you to highligh characters. In Mozilla dragging does nothing - it shows an error/Unavailable cursor, which is a waste of time to the user. Since we are going with OS specific routes, why not use this method? I can file this as a separate bug, but I'm not sure if I should.
Assignee | ||
Updated•16 years ago
|
Product: Core → SeaMonkey
Updated•16 years ago
|
Assignee: hewitt → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: claudius → location-bar
![]() |
||
Comment 32•16 years ago
|
||
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 33•16 years ago
|
||
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
![]() |
||
Comment 34•16 years ago
|
||
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
![]() |
||
Comment 35•16 years ago
|
||
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
![]() |
||
Comment 36•16 years ago
|
||
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
![]() |
||
Comment 37•16 years ago
|
||
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
![]() |
||
Comment 38•15 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
Closed: 15 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•