Closed Bug 37587 Opened 25 years ago Closed 23 years ago

Clicking in address field (URL bar) should select contents

Categories

(SeaMonkey :: UI Design, defect, P2)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: randolph, Assigned: bugzilla)

References

Details

(Keywords: access)

Attachments

(2 files)

patch (this is so lame)
3.32 KB, patch
Details | Diff | Splinter Review
patch w/ focusSelectsAll changes
4.72 KB, patch
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m15) BuildID: When a text field with text in it is first selected, the text cursor appears where ever the click in the field is made. A more common, and in my opinion, more useful behavior is to select all of the text already in that field. Reproducible: Always Steps to Reproduce: 1. Just click in the URL field at the top of a mozilla window Actual Results: Text cursor appears where the click was. Expected Results: All text in the field selected. This is standard behavior on MacOS and MS-Windows.
I really prefer the cursor to be inserted where i click and no selection to automatically trigger. That's what double-clicks are for. When i click once in URL field nowadays it's usually to alter bugnumber at the end of url. Would be annoying if i had to click once more to deselect first. This is not a bug however: Selections have never happened the described way in Moz till now. Chancing severity to enhancement.
Severity: normal → enhancement
I don't agree that all textboxes should fully highlight upon focus, that can be confusing, annoying and unexpected. However, as was the standard in NS 4.72 and IE, I do think the URL bar should be selected upon gaining focus ( though this may have been reported already ). ->Editor Changing this to an enhancement, cc'ing mjudge (selection)
Status: UNCONFIRMED → NEW
Component: User Interface: Design Feedback → Editor
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All
Summary: Text field selection behavior awkward → [RFE] Highlight /Select contents of URL bar upon focus
"I don't agree that all textboxes should fully highlight upon focus, that can be confusing, annoying and unexpected." Hunh? It is standard in Windows and MacOS, as far as I know.
Perhaps it's standard behavior in Win32 for a textbox to automatically have the focus upon initialization in, say, a dialog, however it's definitely not typical behavior to highlight the entire contents of a textbox when you click within it/set focus to it...
"it's definitely not typical behavior to highlight the entire contents of a textbox when you click within it/set focus to it." I just spent a few minutes with MacOS testing this. You are right; the behavior (at least on MacOS) is a good bit subtler. As far as I can tell, upon a dialog gaining focus there is always an indicated text field, which will be selected. Clicks within other text fields in that dialog box will usually simply place the text cursor at the appropriate place within the field. However, if one TABs from field to field, each field is selected in its entirety as it is entered, apparently on the assumption that the user is most likely to want to type a new value in that field if the user changes that field. I don't know how much testing was done on that design; it seems to me "reasonable," but that could just be familiarity talking. Since I'm not currently at school, I can't test MS-Windows, however I believe the behavior is similar except that Windows by default will also allow one to tab to an arbitrary control.
For just any old text entry widget, clicking in it does not select its contents on either Windows or MacOS. (I just checked.) Tabbing to a text widget, or giving it focus by any means other than clicking in it (such as getting focus in a newly-opened window) normally *does* select the widget contents, but that is covered by bug 28583. The location bar could be seen as a special case, where a single click selects the entire contents. But that was discussed in netscape.public.mozilla.ui <http://www.deja.com/=dnc/viewthread.xp?AN=607131090>, and it doesn't seem to be a good idea -- as long as there is a convenient keyboard shortcut for tabbing to the location bar, which would select the entire contents just like it would for any other text entry widget.
Single click to insert the cursor in a text field is standard behavior. You're using a pointer to indicate where you'd like to start typing. If you want to overwrite existing text, you can click and drag a specific section or double click for the whole thing. The URL field *could* be considered different, but that has the potential to be confusing and even frustrating. Consistent double-click/select-all behavior should be sufficient. Resolving as invalid since the current design (pending bug 28583 being fixed) matches standards.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Verified invalid.
Status: RESOLVED → VERIFIED
*** Bug 38774 has been marked as a duplicate of this bug. ***
*** Bug 19217 has been marked as a duplicate of this bug. ***
*** Bug 49622 has been marked as a duplicate of this bug. ***
*** Bug 51580 has been marked as a duplicate of this bug. ***
Filed bug 52784, `Clicking in proxy icon area should select location field contents'.
*** Bug 26848 has been marked as a duplicate of this bug. ***
*** Bug 57299 has been marked as a duplicate of this bug. ***
*** Bug 57299 has been marked as a duplicate of this bug. ***
We have quite a few dupes here. I'm sure there are a few out there that didn't get marked dupes too like bug 59997 which could have been marked a dupe of this. Requesting we re-evaluate the Invalid resolution on this bug.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
I originally spoke against this RFE, but have changed my mind. I'm too used to unix behaviour, where selection auto-copies, so the whole feature would have been a pointless aggrevation, since whatever i pasted after selecting URL field would be the same URL all over again. However: On MSWindows and NT the behaviour in NC4.* is indeed to select the whole text in URL-field on first click. I tested it on a Windows-PC and even liked it. Mac acclaimedly also behave like that. Adding keyword.
Keywords: 4xp
This is a bug for which I think people will disagree quite strongly about preferred behavior. For some people, typing completely new contents into the address field is what they do 99.9 % of the time, so single-clicking to select the field contents is worth the inconsistency with other text fields. But for others, those who often edit URLs in the address bar, the single-click-to-select behavior is extremely annoying. In an effort to please both groups of people, I would like to see bug 28583, bug 31809, and bug 52784, which would all make it easier to select the contents of the address field, implemented for a couple of months (so that Mozilla users can become familiar with those behaviors) before this bug is reconsidered.
Assignee: bdonohoe → ben
Status: REOPENED → NEW
Component: Editor → User Interface: Design Feedback
Depends on: 28583, 31809, 52784
Also bug 30864, which covers pressing Ctrl+Tab to focus (and select the contents of) the address bar.
Depends on: 30864
Adding bug 19446 (need keyboard shortcut to focus location bar) to dependencies.
Depends on: 19446
There's a half-working hidden pref now that selects the entire url when you click the location bar once. Add this to prefs.js in your profile directory to try it: user_pref("browser.urlbar.clickSelectsAll", true); Currently, the pref selects the entire urlbar on mouseup instead of only on normal "clicks", so it's difficult to select a _part_ of the url.
<http://www.nytimes.com/2000/11/30/technology/30STAT.html>: `The most alarming flaw, however, is that you can't highlight the entire Address bar with a single click. You must highlight the current Web address by dragging the mouse over it each time you want to type a new address, an oversight blatant enough to make you wonder exactly how much time the program's designers actually tested Navigator by, say, browsing the Web.' Matthew, the 99% case is usually enough for you to go that way. What's different about this?
This should remain defaulted to false on Unix -- it's infuriating to have the urlbar selected, and we'll get lots of flames if we enable it since it will also overwrite whatever was previously in the clipboard. Previous feedback from Mac people said that they, too, wanted it defaulted off, but if you think that has changed, maybe it's worth raising the issue on mozilla-mac to see what people think.
Blake, if we can cater for the 100-percent case by fixing the dependencies of this bug (which are bugs that need to be fixed anyway), that's better than catering for the 99-percent case. But if the dependencies prove not to be enough, then fine, let's change the behavior. (Also consider that reviewers, such as the one in the NY Times, may rely on typing URLs -- rather than bookmarks -- a lot more than they would with their usual browser, especially with Mozilla's current brain-dead treatment of IE favorites.)
Summary: [RFE] Highlight /Select contents of URL bar upon focus → [RFE] Click to highlight/select contents of URL field
Bug 62496 now tracks some problems that come up when browser.urlbar.clickSelectsAll is enabled.
Nominating for nsbeta1.
Keywords: nsbeta1
*** Bug 63881 has been marked as a duplicate of this bug. ***
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
*** Bug 75523 has been marked as a duplicate of this bug. ***
Currently, only left-clicking selects the URL, even when browser.urlbar.clickSelectsAll is set. IMO this should also happen when right-clicking, just as in NS4 and IE.
nav triage team: There are too many issues here, when we can better articulate what this bug is supposed to mean, we will reconsider. We believe that one-click select all in URL is the correct behavior and believe that there is at least one other bug to addresss that issue. Marking nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Whoa Whoa Whoa, That has to be the most cryptic comment from the Nav Triage team ever. >>There are too many issues here, when we can better articulate what this bug is >>supposed to mean, we will reconsider. The only issue here is that a single click should select the entire contents of the URL field. This is the behavior in Mac and Win NS4.x and IE. The bug is not about focus/select related issues in any other textbox, those are other bugs. >>We believe that one-click select all in URL is the correct behavior and >>believe that there is at least one other bug to addresss that issue. Marking >>nsbeta1- There is no other bug involving a single click to select the URL bar contents. If there is, it is a dup of this bug. (trust me I've tried to find one) If NS feels that this is the correct behavior, then they want to + this bug. If someone with the power to do so could please remove the - to send this bug back through triage it would be greatly appreciated (I can't do it myself) Also, this bug should NOT refer to Linux/Unix, as selecting the URL bar would cause some serious problems with pasting from the system clipboard. No app that I know of (including NS4.x) in linux has this behavior. (and for good reason)
I'm pretty sure this bug is "enable the (hidden) clickSelectsAll pref by default". There are still a few problems with the way Mozilla behaves when the hidden clickSelectsAll pref is turned on, however, which might make it so that fixing this bug would require more than just changing the default pref. See bug 62496, "[meta] problems with browser.urlbar.clickSelectsAll behavior". (Several of bug 62496's dependencies are currently targetted to mozilla0.9.1.) On Linux, Ctrl+L selects the location bar contents without copying them to the clipboard. I think it would be reasonable to do the same thing when clickSelectsAll is enabled and the user clicks in the location bar. (If clickSelectsAll currently *does* blow away the contents of the clipboard on Linux, please file a bug and add it to bug 62496's dependency list.)
[reposting, hopefully with the text wrapped this time] I'm pretty sure this bug is "enable the (hidden) clickSelectsAll pref by default". There are still a few problems with the way Mozilla behaves when the hidden clickSelectsAll pref is turned on, however, which might make it so that fixing this bug would require more than just changing the default pref. See bug 62496, "[meta] problems with browser.urlbar.clickSelectsAll behavior". (Several of bug 62496's dependencies are currently targetted to mozilla0.9.1.) On Linux, Ctrl+L selects the location bar contents without copying them to the clipboard. I think it would be reasonable to do the same thing when clickSelectsAll is enabled and the user clicks in the location bar. (If clickSelectsAll currently *does* blow away the contents of the clipboard on Linux, please file a bug and add it to bug 62496's dependency list.)
Ok, let's do this. Blake was right, I was wrong. Selecting the field contents might be annoying for the tiny minority of users (like me) who edit existing URLs more often than entering new ones, but them's the breaks. And it sure isn't worth having a pref for, that would be laughable. Things which should happen in order for this bug to be marked fixed: (1) If (and only if) the address field does not have focus, hovering over it should use {cursor: default}, not the {cursor: text} usually used for text fields. This indicates that clicking in the field will behave differently from a normal text field. (2) On mousedown of the primary (e.g. left) mouse button, the cursor should change to {cursor: text}. This indicates that text can be selected with the mouse down, just as it can be for any other text field. (3) On mouseup, if (and only if) the cursor position never changed between mousedown and mouseup, the entire contents of the address field should become selected. This way, the click-to-select behavior will not interfere with selection. (4) All traces of the browser.urlbar.clickSelectsAll pref should be removed. (5) If (and only if) the address field does not have focus, on mousedown (not mouseup) of the secondary (e.g. right) mousebutton, the entire contents of the address field should become selected, and the normal text field context menu should open. --> XP Apps: GUI Features.
Assignee: ben → blakeross
Severity: enhancement → normal
Component: User Interface Design → XP Apps: GUI Features
No longer depends on: 19446, 28583, 30864, 31809, 52784
QA Contact: zach → sairuh
Summary: [RFE] Click to highlight/select contents of URL field → Clicking in address field (URL bar) should select contents
No. On Unix, single click has never selected the URL bar contents. It should not. I don't much care if it's a pref or a platform check (though I think many Mozilla users on non-Unix platforms would appreciate the ability to edit the contents of the URL bar without contortions), but we _cannot_ change the behaviour of the URL bar single-click on Unix. Why would we want to? The article that Blake cited, while nicely inflammatory, was certainly not written by a Unix user. I think we should absolutely match 4.x and other-browser behaviour on Windows and Mac, and I think we should match 4.x and other-browser behaviour on Unix. Please don't do this to us.
I believe I am a "typical" user. Windows as well. I am not a developer - I merely use my browser for surfing. Yet I don't understand the need for special casing the address bar. I find it frustrating when I want to merely change part of the address to go to a related site and I have to unhighlight the selection after a single click. Merely give me the ability to double click to select and I have everything I need. Modifying the behaviour to save me a mouse click sounds ludicrous. How many clicks over the course of a browser session are you really saving? Single click inserts caret. Double click (or click and drag) selects. How much simpler could it be?
There are plenty of people (on all three platforms) who dislike the select-all behavior. There is absolutely no need to force this behavior on everybody, especially on platforms where no other application has ever behaved this way. Removing configurability that we already have, which lots of users have asked for, which follows standards for at least one platform, would be silly and pointless. The rest of Matthew's suggestions sound reasonable.
Hmm, this is on my plate now...yikes. Since this is a UI design issue in xpapps land, I'd say it's either up to Matthew or I to make the final call. Since I'm a Windows dork, I'd rather leave it up to him...Matthew, do you still still by your comment earlier today in light of the bloodshed that followed? For what it's worth, shaver's opinion sounds like the most sensible to me...just match 4.x behavior for each platform.
i also strongly agree with shaver's 2001-04-12 08:56 comment, as well as akkana's 2001-04-12 11:13 sentiments re: configurability.
Well of course you do -- you don't have to pay every couple of days to download the bloat expended in implementing this pref. Feh. ...Ahem. This is not (as Akkana supposed) an issue of `no other application ha[ving] ever behaved this way' on Unix, because no other application ever behaved this way on Windows or Mac OS, either ... until Web browsers came along. As I said in my 2000-04-29 comment, the standard for *all* text fields, on *all* platforms, is for a click to place the caret rather than to select the contents of the field. And indeed, this is how early versions of Mozilla (aka `the Netscape Navigator') worked. This suited users just fine, since the early adopters of the Web were technically-minded people, who spent a lot of time hacking at URLs in order to (a) get links which were slightly broken to work or (b) navigate URL hierarchies in the absence of clueful site navigation. However, this quickly changed. The Web became very popular very fast, among non-technical as well as technical people. URLs started to be advertised outside of the Web, and as a result, users had to type them in (rather than follow hyperlinks from other pages) in order to visit them. So for the majority of users, click-to-select saved more time overall than click-to-edit. The sort of people who are CCed to this bug (Shaver, Akkana, Blake, me, et al.), the people who spend a lot of their time hacking off the number from a "http://bugzilla.mozilla.org/show_bug.cgi?id=" URL in order to add a new number, or deleting trailing bits of hierarchy from an URL in an attempt to find a moved page, started to be in a minority which became (relatively) tinier and tinier. So, Navigator for Windows switched from click-to-edit to click-to-select between Mozilla/1.1N and Mozilla/1.22. And Navigator for Mac OS switched from click-to-edit to click-to-select between Mozilla/2.0 and Mozilla/3.0. Were there vicious flamewars amongst the development team, about this particular text field not matching 1.1x or 2.x behavior, or starting to behave differently from any other text field on both of those platforms? Probably. I don't know, I wasn't there. But I bet they didn't have a `1xp' keyword in their bug database. So why didn't Unix change as well? Mike Shaver's argument appears to be that Unix users are generally more computer-literate than those on other platforms, so they are much more likely to want to hack URLs in the address field (rather than just enter new URLs) than users of other platforms are. That's probably true, but I would suggest that (thanks to Linux) it will only be true for another couple of years at most. (I would love to know whether the people who can be regularly seen on Slashdot and elsewhere, expressing their wish that Internet Explorer -- which uses click-to-select -- would be ported to Linux, are (a) current Linux users or (b) current Windows users wanting to migrate.) The other consideration, of course, is the traditional X11 select-to-copy behavior -- a hangover from the days when there were no Unix GUI apps which did formatting (e.g. word processors or spreadsheets), and there were powerful keyboard commands for deleting (^A, ^K, ^W), so the only reason to select text was in order to copy and paste it. But since we're not using the native Motif/GTK/Qt text field, we don't need to copy the URL on click-to-select, just as not using native widgets allows us to avoid the minor bugs which have always been present in the Windows and Mac OS native text fields. Absolutely this bug shouldn't be implemented, at all, until bug 62496 is resolved fixed. Whether it happens after that I'll leave up to Shaver, since he's @mozilla.org and I'm not so he could overrule what I decided in any case. But I predict that even if Unix goes it alone in click-to-edit, it will be forced by user pressure to change to click-to-select within a couple of years. Thus endeth rant.
Depends on: 62496
If we're really waiting for 62496 to be fixed, then pushing this off to .9.1 (to which the bugs on that list are targetted).
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → mozilla0.9.1
Splitting up the tasks mpt listed (2001-04-12 08:23): (1) and (2) are now covered by bug 78082. (3) is covered by bug 62495. (5) is now covered by bug 78083. So this bug is left with enabling browser.urlbar.clickSelectsAll by default (once most of bug 62496's dependencies are fixed), and then eventually (4) removing the pref.
*** Bug 8894 has been marked as a duplicate of this bug. ***
Renominating for nsbeta1 (from nsbeta1-) because bug 8894 was nsbeta1+, and copying rtm nomination from bug 8894. Also adding mostfreq since this bug now has 10 direct dups.
Keywords: nsbeta1- → mostfreq, nsbeta1, rtm
*** This bug has been marked as a duplicate of 8894 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → DUPLICATE
Reopening to switch the duping back, since most of the discussion about the feature is in this bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 8894 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.1 → mozilla0.9.2
I am a Linux user and I would definitely prefer Mozilla to stick to click-to-edit. Should Mozilla implement click-to-select just because it is a lex IE? Especially in a case where IE violates standard behavior for text boxes? In my opinion browsers should not be treated as special cases for UI. Also NY Times articles should not be decision criteria, what if one of them complains about Mozilla not matching IE non-standard rendering... I am accustomed to current behavior and would appreciate at least a pref to be able to keep it.
Vishy, marking this nsbeta1+ on behalf of nav triage. The NY times article wasn't the only source of feedback we got on this issue. In addition to other articles, and newsgroup postings, I've personally heard this complaint many times from users within the company who I would consider close to the target customer demographic. I don't disagree that we should have some platform-specific cases if really necessary (and sounds like from this bug that that is the case), however we need to solve the 80% case, which from all the data I have seen (90+% of our users are windows users and many complained about this behavior) is that a single click should select the URL bar text, and the second place the cursor in the text.
Keywords: nsbeta1 → nsbeta1+
Nav triage: can you please go through the dependencies of bug 62496 and see which of those should also be targetted to mozilla0.9.2? I don't think this bug should be fixed until clickSelectsAll behaves more nicely than it does now.
Vishy, Paul, we need to update our queries to catch stuff like this (blake's stuff anyway).
>But since we're not using the native Motif/GTK/Qt text field, >we don't need to copy the URL on click-to-select [...] Yes you do. That's the copy and paste interface that every x app uses. Any X app that does not quickly gets annoying, once you're used to click-to-copy. Mozilla needs to follow the standards for the platform it is running on. Having a standard interface makes it much easier to use the program. [Heck, even Windows programs on Windows boxes get me annoyed that I can't copy and paste that way. It's easier. Especially since I have a 3-button mouse.] Going against select-to-copy is as bad as deciding the Mac port will use Command-C to cut (after all, cut starts with C, and we all use cut more often to move text around, right?) and Command-X to copy (short for Xerox[R]).
anthony.derobertis@crossmedia.net: you'll still be able to select the URL manually if you want to copy the URL to the transient X clipboard. See bug 62495, "clickSelectsAll should not trigger if you're selecting text".
Is there no way on X to make click-in-url-bar-then-type overwrite, without destroying the clipboard? Netscape 4 and Mozilla have always behaved somewhat funky with X's clipboard, and often exibit very abnormal copy/pasting behavior. I'd go in to examples but this doesn't seem to be the place. If there is a way, personally, i'd prefer the IE-like behavior on my UNIX systems. Sure I sometimes edit URLs, but for all users I'm sure new URLs are more common then editing. So click-<end> to edit, is a lot easier then click-drag, or click-<home>-<shift+end>, or click-click to edit.
This is really easy to fix. The only reason I haven't done so yet is because everyone's still fighting about what to do on each platform...
Status: REOPENED → ASSIGNED
Blake, I think we should proceed by a) fixing this, b) adding a pref. If we can then set the pref differently on different platforms, let's do it. If not, I think Linux users are savvy enough to find the pref and switch it. I saw more instances of this suggestions (single click URL field selection) in the newsgroup feedback for 6.1 PR1.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
*** Bug 87205 has been marked as a duplicate of this bug. ***
I much prefer standard edit field behavior. Having the URL field as a special special case _is_ annoying to me. Maybe whoever first made it a special case should have inverted the click-edit / double-click-select behavior so that quick editing would still be available, but a pref would be even better. The best place for the pref would, IMHO, be in the Preferences dialog. Click-select then <end> key is not satisfactory because I've already reached for the mouse and adding the additional reach for the <end> key is just as slow as click-select->wait->click-edit (the IE behavior) If the final say is that it should merely be platform-specific and not be available in the Preferences dialog, maybe someone should sneak in an Easter Egg to enable stadard edit field behavior (^; Failing that, I'd rather download the source of every major release, set the standard behavior myself, and compile than put up with click-select. From the responses in this thread, I guess I'll have to get back into my programming books (-; IIsi 50MHz Cincinnati, Ohio, USA iisi50mhz@aol.com
Defaults to off for linux, on for everything else, I can't believe we have a pref for this... I saw lots of pr1 feedback about this too, but that doesn't mean anything, because we don't know what the feedback will be once it's on. Ideally we'd have released PR1 with click-selects-all behavior...
Whiteboard: fix in hand
iisi50mhz@aol.com: see mpt's 2001-04-23 07:32 comments in bug 62491. This bug is marked as depending on bug 62491, which may or may not mean that 62491 will be fixed first. Blake: does your patch fix any of the dependencies?
78082 would be easy enough to fix, but this doesn't fix it. It fixes 78083.
Also fixes bug 62493, and basically makes bug 62495 a moot point.
Depends on: 87348
I'd like to see the changes in navigator.js to have a try/catch around them. On blur, why do we remove the selection? Wouldn't it be better to just let the selection lose focus? In all.js, there should be a space after the ',' (before "true") to be more like other prefs in that file. unix.js should also have a space after the ',' to be like the other prefs in there.
Removing the selection onblur is probably a workaround for bug 36848, "Should only be one text selection per window".
If that were the case, we'd always do it; not just for this preference. If we have to keep it, I'd prefer URLBarBlurHandler to check for gClickSelectsAll > 0 (or == 1). I recommend removing it and testing it to confirm it's not necessary. :-)
I did try removing that. Then what happens is that the next time you click in the url bar after it's already blurred once, you end up not selecting all the text, because it's remembering the previous selection (so the click is cancelling the previous selection). What needs a try/catch, and why? Theoretically (and by definition), the textbox can't be blurred unless it already took focus.
with the addition of the try/catch, r=brade Please file a bug on the issue of the selection needing to be removed; then your comment could point to that bug. :-)
<summary of an email I sent to blake> This bug fixes both the clicking and tabbing to URL bar selection problem. I suggest a change in the name of the pref to |focusSelectsAll| and a likewise change to the variable ->gFocusSelectcAll. I will post a diff that makes these changes and removes the fix for bug 83588 which only fixes the tabbing case. </summary>
Keywords: access
Oops, I thought you just wanted to change the variable name, not the pref. I don't think we should change the pref because of users who are using old profiles and already have the old one. I don't think the benefit outweighs the cost.
Hmm... then keep the variable name the same. No sense confusing things. But definitely take out the code for the keyup stuff I did. You can see it in my diff -- navigator.xul navigator.js -- the function and the handler registration.
Keywords: nsBranch
Whiteboard: fix in hand → fix in hand, needed for accessibility
Keywords: vtrunk
blake, i'd like to just land this as part of the accessibility landing on the 0.9.2 branch today. Does that work for you?
Whiteboard: fix in hand, needed for accessibility → fix in hand, needed for accessibility, PDT+
It wouldn't make sense to rename clickSelectsAll to focusSelectsAll, because the pref should only affect clicking. Tabbing to a text field should always select the contents of that text field (bug 28583).
What is the "accessibility landing on the 0.9.2 branch"? Are we actually taking "landings" on the branch at this late date - or did you just mean a set of targeted bugfixes? Does this bug need to be PDT+?
verified using the following comm trunk builds: linux 2001.07.05.08: tabbing to URLbar inserts cursor at the end of the field contents; single-clicking places the cursor where the mouse pointer is located. [both expected by default on unix.] winnt 2001.07.05.09: tabbing to and single-clicking in the URLbar selects/highlights its entire contents. mac 2001.07.05.08: tabbing to and single-clicking in the URLbar selects/highlights its entire contents. removing vtrunk kw. yes, this ought to be checked into the branch.
Keywords: vtrunk
Can something be done to get this to work on UNIX, without trashing the clipboard? I and I'm sure many other UNIX users would prefer click selects all. If the clipboard needs to be trashed for 1.0, I'd still like a pref to turn this on, I think the benefits would outweigh the disadvantage. Could a workaround be just not highlighting the text, but <click>-<type> would have the effect of overwriting what was there anyway (under UNIX only). This would have to be off by default since it's non-obvious, but would be a nice tunable feature for power users. <click>-<arrows/home/end/backspace> would skip this special case clearing. (Sorry, just trying to dump my brain before this bug gets buried, leaving for vacation in a few hours)
Have you tried this? As far as I know a mechanical content selection (e.g. through javascript, as is done here) does not overwrite the clipboard at all. Only user drag select or double-click select does.
vishy/all, accessiblity landing on the branch is for a key embedding customer that will also use the branch for shipping. is this fix ready to go on the branch?
Yes, this fix is all ready. John, are you going to land it?
This was checked into the branch wed 4 july.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Whiteboard: fix in hand, needed for accessibility, PDT+
Is there a pref to set so this works on UNIX?
user_pref("browser.urlbar.clickSelectsAll", true);
verified fixed on the branch using the following comm branch builds: linux 2001.07.09.04: single-clicking places the cursor where the mouse pointer is located. [expected by default on unix.] winnt 2001.07.09.05: single-clicking in the URLbar selects/highlights its entire contents. mac 2001.07.09.03: single-clicking in the URLbar selects/highlights its entire contents.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: