Input field focus behavior

[Yash Malik]

Hi all,

We (the Chrome VR team) are working on adding text input support to our UI framework. I had some questions regarding what's normative for focus. 

When does an element lose focus? I see that if I have an input field, clicking outside of it, loses focus. But for example the omnibox on desktop, when I'm editing a url and click on the toolbar, it still has focus.

Is it correct to say that input fields on the web will always lose focus when the user clicks outside of it, but a UI framework may choose to act differently from case-to-case?

Thanks,

Yash 

[Dave Tapuska]

I believe there are two concepts of focus.

1) Which field on the page has focus (the target of keyboard events)

2) Whether the frame has focus or not.

I believe the frame loses focus when the omnibox gets focus but #1 doesn't loose focus.

--
You received this message because you are subscribed to the Google Groups "input-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+unsubscribe@chromium.org.

[Dave Tapuska]

I believe there are two concepts of focus.

1) Which field on the page has focus (the target of keyboard events)

2) Whether the frame has focus or not.

I believe the frame loses focus when the omnibox gets focus but #1 doesn't loose focus.

On Fri, Nov 24, 2017 at 2:47 PM, 'Yash Malik' via input-dev <inpu...@chromium.org> wrote:

[Ryan Landay]

Note that we used to tie the behavior of changing the selection and changing focus in a webpage in Chrome, but it was removed for performance reasons; it is now possible to use JavaScript to set a selection somewhere else on a page without moving focus. WebKit refused to make this change because the standard platform behavior on macOS is that focus and selection are supposed to be unified (so in Safari, moving the selection also moves focus).

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2Q6ja5CNMpw

[Yash Malik]

Thanks for the responses,

Luckily we don't have the same compat constrains as input fields on the web. In a more general sense, I guess what I'm wondering is if text fields on most UI frameworks lose focus when anything else other than the text field is clicked?

To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org.

[Ryan Landay]

I think that’s generally the default behavior, yes. Clicking somewhere generally tries to focus to whatever you clicked on (and if it can’t take focus, it at least unfocused the currently focused element). I assume the Chrome toolbar has custom behavior to not defocus the ominbox when clicked on and that’s why it’s not exhibiting this behavior.

[Steve Kobes]

That isn't the convention in Windows at least - if you click something that isn't focusable, like blank space in a dialog box, it won't remove focus from whatever had it before.

The web complicates this because the document is considered focusable to allow arrow scrolling and such.  So clicking outside an <input> field, but inside the containing frame, will always move focus away from the <input>.  But clicking unfocusable parts of the browser UI (toolbar / title bar) won't unfocus anything.

To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+unsubscribe@chromium.org.