STR - in metro fx, open gmail - tap compose (see new message popup. Often takes a couple of taps) - tap to field. see keyboard pop up. enter an part of an address in the address book, tap on the entry in the dropdown (keyboard automatically dismissed) - try to add another recipient. As soon as you tap the to field again, the keyboard pops up & focus on edit box disappears, the keyboard disappears. - last step repeats.

Yeah. This is ugly. I wonder if Gmail is doing something different for IE than it's doing for Metro Firefox. We need to not roll up the OSK when the Gmail auto-complete widget pops up or when the user interacts with it.

p=3?

I did some investigation comparing focused element reported by FocusManager GetFocusedElement() and Accessible GetFocusedChild(), and they gave me different elements. Accessible returns the highlighted div from the autocomplete popup, whereas focus manager returns the recipient textarea. We're using accessible focused div element when responding from UIA queries from windows, which then hides the keyboard. I considered changing https://mxr.mozilla.org/mozilla-central/source/widget/windows/winrt/UIABridge.cpp to use focus manager, but that would probably completely break accessibility. One of the possibilities pointed by #accessibility is that gmail may be using WAI-ARIA, but I couldn't find any attributes when debugging. CC'ing dbolter per jimm's suggestion.

(In reply to Rodrigo Silveira [:rsilveira] from comment #3) > I did some investigation comparing focused element reported by FocusManager > GetFocusedElement() I assume a11y::FocusManager? > and Accessible GetFocusedChild(), and they gave me > different elements. which accessible you call the method at? Basically Accessible::FocusedChild returns what a11y::FocusManager returns.

(In reply to alexander :surkov from comment #4) > > I did some investigation comparing focused element reported by FocusManager > > GetFocusedElement() > > I assume a11y::FocusManager? > Sorry, I meant the DOM focus manager: https://mxr.mozilla.org/mozilla-central/source/dom/base/nsFocusManager.cpp#413 I was looking for whatever document.activeElement returns. > > and Accessible GetFocusedChild(), and they gave me > > different elements. > > which accessible you call the method at? Basically Accessible::FocusedChild > returns what a11y::FocusManager returns. We're calling this a11y::Accessible GetFocusedChild https://mxr.mozilla.org/mozilla-central/source/accessible/src/generic/Accessible.cpp#781 like this https://mxr.mozilla.org/mozilla-central/source/widget/windows/winrt/UIABridge.cpp#179

a11y::FocusManager may return different results than DOM nsFocusManager since a11y focus may be different than DOM focus. Thus it'd be wrong to switch to nsFocusManager when you need a11y focus. I'd say you need to figure out where the problem is, it is either in gmail or a11y::FocusManager. You can enable a11y focus logging (export A11YLOG=focus), it's usually helpful to debug things of this sort.

I don't know if we or gmail fixed it, but it WFM fine now.