Re: [whatwg] Should scrollbars move focus?
On Mon, 22 Oct 2012, Ojan Vafai wrote: On Fri, Oct 19, 2012 at 3:43 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 19 Oct 2012, Elliott Sprehn wrote: I was working on a bug recently where authors had complained about WebKit's behavior where clicking a scrollbar unfocuses the activeElement. What's particularly quirky is that the window scrollbar never moves focus in any browser I tried, but overflow scrollbars inside the page *do* move focus in WebKit, IE and Opera but not in Gecko. From the spec's point of view, I think this is just something where you're supposed to try to match the host platform conventions. This doesn't have to be specced, but it also doesn't really seems to be a platform convention issue. The platforms that have scrollbars are all the same (i.e. clicking on the scrollbar never moves focus) and no browser fuller matches platform that convention. On Mac, clicking the scrollbar moves focus in at least some native apps. For example, TextEdit: Type enough text to have a scrollbar, open the fonts panel (Command+T), click the search field, then click the scroll bar in the document window, and focus moves to the document window. But it may just be that the conventions are more subtle than that (e.g. window gets focused, but not the specific widget). Gecko's behavior is most consistent with that, except Gecko *does* move focus if you click on a textarea scrollbar. It seems especially bad that you get a different behavior if you click on the scrollbar of the window vs. the scrollbar of an overflow:auto element that fills the window IMHO all the cases where this is inconsistent with the platform conventions are bugs, but that's a UA decision really. Anyway, if we're agreed that it's out of scope of the spec, I'm good. :-) On Fri, 26 Oct 2012, Elliott Sprehn wrote: So what's the consensus here? Should WebKit have Gecko's behavior? Should we unify the world and make scrollbars never move focus even on textarea? :) I think it should just match the native platform conventions, but really that's up to you. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should scrollbars move focus?
From: o...@chromium.org Date: Thu, 1 Nov 2012 10:45:07 -0700 I didn't test nested scrollbars in Windows. I believe Elliott may have. I did test them on Mac and Ubuntu. Clicking on nested scrollbars doesn't move focus even if the scrollable element is focusable. On Ubuntu, clicking on scrollbars doesn't even change window focus if the scrollbar is in a different window. On Windows (tested on 7 using the Resource Monitor and Command Prompt properties windows), interacting with scrollbars will focus the window, but not the scrollable item itself (i.e. preserving the focus within the window). However, Internet Explorer (9, on Windows 7), will move the focus to the scrollable element (for all types in Robert's test page). James
Re: [whatwg] Should scrollbars move focus?
Wouldn't this be considered a browser-specific implementation bug/inconsistency then? It seems that it's done because the scrollbars have to be in the DOM, and therefore act as elements in the DOM tree (clicking in a random div for instance does change focus, so the implementation is correct in the sense of HTML). However, it doesn't look like this ever was looked at. It's just the bi-product of the way the DOM is typically implemented. Shouldn't it be fixed? Or rather, can it without breaking DOM functionality in the browser? On 2012-11-02 8:02 AM, James Ross sil...@warwickcompsoc.co.uk wrote: From: o...@chromium.org Date: Thu, 1 Nov 2012 10:45:07 -0700 I didn't test nested scrollbars in Windows. I believe Elliott may have. I did test them on Mac and Ubuntu. Clicking on nested scrollbars doesn't move focus even if the scrollable element is focusable. On Ubuntu, clicking on scrollbars doesn't even change window focus if the scrollbar is in a different window. On Windows (tested on 7 using the Resource Monitor and Command Prompt properties windows), interacting with scrollbars will focus the window, but not the scrollable item itself (i.e. preserving the focus within the window). However, Internet Explorer (9, on Windows 7), will move the focus to the scrollable element (for all types in Robert's test page). James
Re: [whatwg] Should scrollbars move focus?
On Fri, Nov 2, 2012 at 6:21 AM, Etienne Levesque Guitard etienn...@gmail.com wrote: Wouldn't this be considered a browser-specific implementation bug/inconsistency then? If you're referring to IE's reported behavior, I would say that yes, it's not gospel regarding platform conventions, and it may not even intentionally deviate. I verified James' testing and am sufficiently convinced that the Windows convention, like other platforms, seems to be to not change focus due to scrollbar clicks. That makes me lean towards the change Gecko and WebKit to never focus camp. PK
Re: [whatwg] Should scrollbars move focus?
On Wed, Oct 31, 2012 at 4:17 PM, Peter Kasting pkast...@google.com wrote: On Wed, Oct 31, 2012 at 4:08 PM, Ojan Vafai o...@chromium.org wrote: On Wed, Oct 31, 2012 at 3:46 PM, Robert O'Callahan rob...@ocallahan.org wrote: I think what's happening here in Gecko is that a click on a focusable element moves focus, and a click on an element's scrollbars counts as a click on the element. So clicking on the scrollbar of a textarea or contenteditable div (or even a button containing content with a scrollbar, if you're mad) moves focus to that element. I think this is quite reasonable actually. Example: http://people.mozilla.org/~roc/scrollbar-focus.html I see. Thanks for the clarification. I don't feel strongly about this. Either direction seems fine. Although, it doesn't violate every native platform's scrollbar convention. The behavior Robert describes seems theoretically reasonable to me as well. On the one hand, I think it'd be more consistent if clicking on scrollbars just never moved focus. Here's a case that's kind of weird if you do move focus: div tabIndex=-1 style=width: 100px; height: 100px; overflow: auto input div style=height:200px/div /div If you focus the input, then click on the scrollbar, the input gets blurred. I suppose the opposite case is worse though: div contentEditable style=width: 100px; height: 100px; overflow: auto div style=height:200px/div /div Clicking on the scrollbar wouldn't focus the element, so you wouldn't get a text input cursor unless you clicked inside the scrollable area. I remain on the fence. :) Ojan, can you say how you tested the platform conventions? On Windows I'm having a hard time finding an app with multiple scrollable elements that uses native scrollbars. (For example, Visual Studio doesn't use native scrollbars.) I didn't test nested scrollbars in Windows. I believe Elliott may have. I did test them on Mac and Ubuntu. Clicking on nested scrollbars doesn't move focus even if the scrollable element is focusable. On Ubuntu, clicking on scrollbars doesn't even change window focus if the scrollbar is in a different window.
Re: [whatwg] Should scrollbars move focus?
It would be trivial to change Gecko so that clicking on scrollbars never moves focus. So I'm on the fence too, although obviously it would be lower-risk for us to not change anything :-). Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28]
Re: [whatwg] Should scrollbars move focus?
I think Ubuntu has the right behavior, similar to how you can scroll windows in OS X (with the scroll wheel) even if they're not in a focus; a huge usability improvement over Windows when doing side-by-side document editing. If anything, I believe the user agent should never change platform behavior. If platform A has behavior X and platform B has behavior Y, then the user agent should behave as X on A and B on Y. Which is to say: scroll bars should never change focus, regardless of the case (as far as I know all platforms follow this convention) Étienne On 2012-11-01 7:08 PM, Robert O'Callahan rob...@ocallahan.org wrote: It would be trivial to change Gecko so that clicking on scrollbars never moves focus. So I'm on the fence too, although obviously it would be lower-risk for us to not change anything :-). Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28]
Re: [whatwg] Should scrollbars move focus?
Does anyone from Mozilla know why textarea scrollbars are special-cased in Gecko? Would be good to know if there is a web compatibility requirement here. On Fri, Oct 26, 2012 at 12:17 AM, Elliott Sprehn espr...@gmail.com wrote: On Mon, Oct 22, 2012 at 6:28 PM, Ojan Vafai o...@chromium.org wrote: ... This doesn't have to be specced, but it also doesn't really seems to be a platform convention issue. The platforms that have scrollbars are all the same (i.e. clicking on the scrollbar never moves focus) and no browser fuller matches platform that convention. Gecko's behavior is most consistent with that, except Gecko *does* move focus if you click on a textarea scrollbar. It seems especially bad that you get a different behavior if you click on the scrollbar of the window vs. the scrollbar of an overflow:auto element that fills the window So what's the consensus here? Should WebKit have Gecko's behavior? Should we unify the world and make scrollbars never move focus even on textarea? :) - E
Re: [whatwg] Should scrollbars move focus?
On Thu, Nov 1, 2012 at 11:16 AM, Ojan Vafai o...@chromium.org wrote: Does anyone from Mozilla know why textarea scrollbars are special-cased in Gecko? Would be good to know if there is a web compatibility requirement here. I don't know of one off the top of my head. I can't see how it could be a compatibility requirement. I think what's happening here in Gecko is that a click on a focusable element moves focus, and a click on an element's scrollbars counts as a click on the element. So clicking on the scrollbar of a textarea or contenteditable div (or even a button containing content with a scrollbar, if you're mad) moves focus to that element. I think this is quite reasonable actually. Example: http://people.mozilla.org/~roc/scrollbar-focus.html Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28]
Re: [whatwg] Should scrollbars move focus?
On Wed, Oct 31, 2012 at 3:46 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Nov 1, 2012 at 11:16 AM, Ojan Vafai o...@chromium.org wrote: Does anyone from Mozilla know why textarea scrollbars are special-cased in Gecko? Would be good to know if there is a web compatibility requirement here. I don't know of one off the top of my head. I can't see how it could be a compatibility requirement. I think what's happening here in Gecko is that a click on a focusable element moves focus, and a click on an element's scrollbars counts as a click on the element. So clicking on the scrollbar of a textarea or contenteditable div (or even a button containing content with a scrollbar, if you're mad) moves focus to that element. I think this is quite reasonable actually. Example: http://people.mozilla.org/~roc/scrollbar-focus.html I see. Thanks for the clarification. I don't feel strongly about this. Either direction seems fine. Although, it doesn't violate every native platform's scrollbar convention.
Re: [whatwg] Should scrollbars move focus?
On Wed, Oct 31, 2012 at 4:08 PM, Ojan Vafai o...@chromium.org wrote: On Wed, Oct 31, 2012 at 3:46 PM, Robert O'Callahan rob...@ocallahan.org wrote: I think what's happening here in Gecko is that a click on a focusable element moves focus, and a click on an element's scrollbars counts as a click on the element. So clicking on the scrollbar of a textarea or contenteditable div (or even a button containing content with a scrollbar, if you're mad) moves focus to that element. I think this is quite reasonable actually. Example: http://people.mozilla.org/~roc/scrollbar-focus.html I see. Thanks for the clarification. I don't feel strongly about this. Either direction seems fine. Although, it doesn't violate every native platform's scrollbar convention. The behavior Robert describes seems theoretically reasonable to me as well. Ojan, can you say how you tested the platform conventions? On Windows I'm having a hard time finding an app with multiple scrollable elements that uses native scrollbars. (For example, Visual Studio doesn't use native scrollbars.) PK
Re: [whatwg] Should scrollbars move focus?
On Mon, Oct 22, 2012 at 6:28 PM, Ojan Vafai o...@chromium.org wrote: ... This doesn't have to be specced, but it also doesn't really seems to be a platform convention issue. The platforms that have scrollbars are all the same (i.e. clicking on the scrollbar never moves focus) and no browser fuller matches platform that convention. Gecko's behavior is most consistent with that, except Gecko *does* move focus if you click on a textarea scrollbar. It seems especially bad that you get a different behavior if you click on the scrollbar of the window vs. the scrollbar of an overflow:auto element that fills the window So what's the consensus here? Should WebKit have Gecko's behavior? Should we unify the world and make scrollbars never move focus even on textarea? :) - E
Re: [whatwg] Should scrollbars move focus?
On Fri, Oct 19, 2012 at 3:43 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 19 Oct 2012, Elliott Sprehn wrote: I was working on a bug recently where authors had complained about WebKit's behavior where clicking a scrollbar unfocuses the activeElement. What's particularly quirky is that the window scrollbar never moves focus in any browser I tried, but overflow scrollbars inside the page *do* move focus in WebKit, IE and Opera but not in Gecko. This behavior seems unfortunate because it means scrolling a form inside an overflow div moves focus from where you were typing and it's also really weird that window scrollbars are special. What's the correct behavior here? It would be best if all the browsers could be consistent, but I'm not sure the existing common behavior is best. :) From the spec's point of view, I think this is just something where you're supposed to try to match the host platform conventions. This doesn't have to be specced, but it also doesn't really seems to be a platform convention issue. The platforms that have scrollbars are all the same (i.e. clicking on the scrollbar never moves focus) and no browser fuller matches platform that convention. Gecko's behavior is most consistent with that, except Gecko *does* move focus if you click on a textarea scrollbar. It seems especially bad that you get a different behavior if you click on the scrollbar of the window vs. the scrollbar of an overflow:auto element that fills the window
[whatwg] Should scrollbars move focus?
I was working on a bug [1][2] recently where authors had complained about WebKit's behavior where clicking a scrollbar unfocuses the activeElement. What's particularly quirky is that the window scrollbar never moves focus in any browser I tried, but overflow scrollbars inside the page *do* move focus in WebKit, IE and Opera but not in Gecko. This behavior seems unfortunate because it means scrolling a form inside an overflow div moves focus from where you were typing and it's also really weird that window scrollbars are special. What's the correct behavior here? It would be best if all the browsers could be consistent, but I'm not sure the existing common behavior is best. :) [1] https://bugs.webkit.org/show_bug.cgi?id=96335 [2] http://code.google.com/p/chromium/issues/detail?id=51469 - Elliott
Re: [whatwg] Should scrollbars move focus?
On Fri, 19 Oct 2012, Elliott Sprehn wrote: I was working on a bug recently where authors had complained about WebKit's behavior where clicking a scrollbar unfocuses the activeElement. What's particularly quirky is that the window scrollbar never moves focus in any browser I tried, but overflow scrollbars inside the page *do* move focus in WebKit, IE and Opera but not in Gecko. This behavior seems unfortunate because it means scrolling a form inside an overflow div moves focus from where you were typing and it's also really weird that window scrollbars are special. What's the correct behavior here? It would be best if all the browsers could be consistent, but I'm not sure the existing common behavior is best. :) From the spec's point of view, I think this is just something where you're supposed to try to match the host platform conventions. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should scrollbars move focus?
On Fri, Oct 19, 2012 at 3:34 PM, Elliott Sprehn espr...@gmail.com wrote: I was working on a bug [1][2] recently where authors had complained about WebKit's behavior where clicking a scrollbar unfocuses the activeElement. What's particularly quirky is that the window scrollbar never moves focus in any browser I tried, but overflow scrollbars inside the page *do* move focus in WebKit, IE and Opera but not in Gecko. This behavior seems unfortunate because it means scrolling a form inside an overflow div moves focus from where you were typing and it's also really weird that window scrollbars are special. What's the correct behavior here? It would be best if all the browsers could be consistent, but I'm not sure the existing common behavior is best. :) [1] https://bugs.webkit.org/show_bug.cgi?id=96335 [2] http://code.google.com/p/chromium/issues/detail?id=51469 I don't have strong opinions, and would be swayed by a decent rationale, but I lean toward making scrollbars never steal focus. It's weird that you can mousewheel or touch scroll without killing your focus, but using the bar steals it. ~TJ
