This is probably a dupe (sorry, not enough time to check) but the contents of the location bar on need to be selected on a single click into the location bar. This currently works on Windows, but not on OS X and Linux.
This is actually an option in about:config to set to true for Linux/Mac : browser.urlbar.clickSelectsAll never quite understood the logic for that, I guess it is to copy the behaviour of nautilus. That's the first thing I change when I install Linux on a machine. Currently, setting it to True breaks the location bar in Linux, see bug #406360
rational: there are three things the user may do when giving the location bar focus (I believe these are in order of popularity): A) enter an entirely new location (using the awesomebar) B) copy the URL to the clipboard to share it C) edit the existing URL to go to a new location based on the current location Selecting the entire URL on a single click makes A and B considerably easier, and it makes C harder. I would argue that mainstream users do A and B far more than they do C. In fact, I believe C is limited primarily to technical users since the behavior of manipulating URL implies both some knowledge about the URL's structure, and the structure of the site itself. Additionally, regardless of how technical you are most non-human readable URLs are not easily edited (like google search results, or pages at Amazon).
Component: Places → Location Bar and Autocomplete
QA Contact: places → location.bar
This should definitely not happen on the GTK port, where the act of selecting text overwrites the PRIMARY selection. Doing this would mean there would be no way to edit the location bar without overwriting the text on PRIMARY. I'm not sure why the pref is flipped for Mac, though -- I thought the intent was to flip it only for X11-based systems. In GTK Mozilla, double-click does select the entire location bar, as it should. (In a normal text field double-click does word-by-word text selection.) This is consistent with Konqueror and Epiphany as well (which both have the same three distinct behaviors for single-click in URL bar or text field, double-click in URL bar, and double-click in textfield). See also bug 190615.
Alex, you missed: D) Paste a url that she wants to go to. This would break completely if PRIMARY got clobbered on focus. Not sure where it fits on your list. For me it's about as common as B.
I don't understand what you defined as PRIMARY selection? Are you talking about something selected in the page before selecting the URL bar? What overwriting are you talking about? There is not copying or pasting involved here. I don't understand the reasons explained for not setting it to true by default.
Pascal, have you used X? In brief, there are two selections that matter to modern X apps: PRIMARY and CLIPBOARD. Selecting something copies it into PRIMARY (more or less). Middle click pastes PRIMARY. Selecting the copy or paste menuitems place the data on CLIPBOAD and read from CLIPBOARD. PRIMARY is basically a drag-and-drop where you can release your mouse button during the drag. That makes it a lot more useful (and more used) than typical drag-and-drop. The most common way to copy stuff from point A to point B is in fact using PRIMARY. So any time you select something there is "copying involved" from the user's point of view.
I have been a linux user for a couple of years now and never used this, that said I am a laptop user and don't have a third button on my touchpad that would help using this feature. I'll plug an external mouse to test that. Is there some study on how current linux users (not linux über-geeks but real users ;) ) want that?
> D) Paste a url that she wants to go to. Good call, so that's three common interactions that are streamlined, and one that is made worse (which I also believe is an uncommon interaction). + A) enter an entirely new location (using the awesomebar) + B) copy the URL to the clipboard to share it + C) Paste a url - D) edit the existing URL to go to a new location based on the current location >So any time you select something there is "copying involved" from the user's >point of view. If you are going to edit the URL aren't you likely going to make a selection anyway? Or do click and drag selections not copy into PRIMARY? Is there any way for us to select the contents without overwriting PRIMARY?
(In reply to comment #9) > If you are going to edit the URL aren't you likely going to make a selection > anyway? Or do click and drag selections not copy into PRIMARY? They do, but there are other ways to edit the location bar, e.g. by using the keybord. > Is there any way for us to select the contents without overwriting PRIMARY? There used to be a way by clicking on the site icon (bug 52784), but that got removed recently in bug 400935.
>I have been a linux user for a couple of years now and never used this Do we have any sense of what percent of users on linux know about PRIMARY? For instance, if it is 5%, then an ABC+ D- change is still an overall win. If it is 95%, then the change will do more harm than good. Possible solutions to a problem in software development are often ruled out due to nasty boundary cases. However, in interaction design simply ignoring boundary cases is often the only way to make life easier for the vast majority of users, and improve the overall interface.
Mac history: * Bug 233977 (Firefox) * Bug 345886 (Firefox) * Bug 134649 (Seamonkey) * Bug 301530 (Camino) Linux history: * Bug 226853 (Firefox) * Bug 393828 (Firefox) * Bug 282634 (Firefox)
Jesse: thanks for the history, I quickly scanned through all of the comments in those bugs. Arguments against the change revolve primarily around breaking platform conventions and human interface guidelines as opposed the nature of the control and user behavior. I'm personally all for system integration (as are all of the mac user's I've seen begging us to fix bugs like 231754). However, this really isn't any normal text field. For instance, we provide a drop down arrow on OS X, even though that totally breaks platform conventions (the only other similar control we could find is in Microsoft office for the mac). Beltzner: assuming I got these behaviors in the correct order, can we revisit this pref? + A) enter an entirely new location (using the awesomebar) + B) copy the URL to the clipboard to share it + C) Paste a url - D) edit the existing URL to go to a new location based on the current location
Alex, I think you misunderstood. The "Paste a URL" use case becomes impossible if the URL to be pasted is in PRIMARY. You're listing it as becoming easier. Pascal, every single Linux user I know (most of whom use it on desktops, with the usual 3-button mice desktops have, and most of whom are not at all anything resembling uber-geeks) uses PRIMARY. The very few that didn't know about it to start with (because they'd never used Linux before) loved it once it was pointed out to them...
Unless the list in comment 14 is for Mac, in which case I agree with the +/- annotations.
>Unless the list in comment 14 is for Mac, in which case I agree with the +/- >annotations. yeah, I wasn't thinking about the case of PRIMARY, so the +/- distinctions vary by platform.
Can we separate the discussion about what to do on Mac from the discussion about what to do on GTK? If we combine them, I'm sure Mac's needs will win out, but there's no need for the pref to be the same on both.
>Can we separate the discussion about what to do on Mac from the discussion >about what to do on GTK? Sure, I've given this bug to GTK since it has the discussion of PRIMARY, and I'm splitting out a new bug for OS X (bug 406706)
OS: All → Linux
Hardware: PC → All
Summary: Contents of the location bar should be selected on single click → Contents of the location bar should be selected on single click, GTK
For GTK, I think comment 4 nails things. And to be entirely honest, I'm not sure why these discussions (about things that have been discussed, decided, and work) keep happening again and again. It's an incredible waste of time...
(In reply to comment #19) > And to be entirely honest, I'm not sure why these discussions (about things > that have been discussed, decided, and work) keep happening again and again. > It's an incredible waste of time... ::rolleyes:: First: times, UI paradigms, and user audiences change; so too must some decisions about what is the best default interaction or behaviour. I'm quite sure that this happens in non-UI areas of Mozilla's codebase as well. Revisiting decisions is healthy and should be encouraged. There is nothing saying that you needed to "waste your time" with this bug, and I'd appreciate your trust. Second: your and dbaron's input on this bug has been useful, as has Jesse and Gavin's review of the history of these bugs. Alex's goal here was definitely well motivated, and I agree with his analysis that (PRIMARY notwithstanding, see below) in the majority of cases, selecting the entire URL upon focusing the field gets the desired result - in fact, this was the outcome of bug 37587, which charted a very similar course to this one. Finally: the dataloss potential of this bug for systems that support PRIMARY is enough to scare me off insisting on XPP for this function. I suppose we could try to do something funky like not have the selection on first click actually overwrite PRIMARY, but then we'd get inconsistency with the OS. Linux's support for PRIMARY basically makes this impossible to do on GTK; we can reconsider this if that ever changes. Marking WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Flags: blocking-firefox3? → blocking-firefox3-
Resolution: --- → WONTFIX
We could do the opposite of bug 393828 and select the address without writing to the PRIMARY selection. Obviously, that would be confusing.
Then it might be less obvious how to get the current URL *into* PRIMARY.
>We could do the opposite of bug 393828 and select the address without writing >to the PRIMARY selection. Obviously, that would be confusing. Yeah, I'm worried that would be too confusing as well. We would need to use a different color for the special case selection or something. Ideally user's on linux wouldn't need to triple click the location bar for the vast majority of location bar interactions, but I don't see an obvious way for us to get around the PRIMARY issue. Just to brainstorm a little: -a left click in the location bar selects everything, over writing primary -a middle click in the location bar pastes primary and replaces the current URL So this make it easy for users to get URLs into and out of primary, and makes the behavior consistent. As I understand it the remaining issue is that user may have placed the only copy of their masters thesis in primary, and when they left click on the location bar they experience dataloss?
You need to log in before you can comment on or make changes to this bug.