1211234 - [non-e10s] touchscreen keyboard shows up for password fields even if ui.osk.enabled is false

Status: RESOLVED WONTFIX

(Core :: Widget: Win32, defect, P3)

Description

[Seo Suchan]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151001142456

Steps to reproduce:

1. grab a windows 10 tablet.
2. touch a password input box. (like in some kind of login form)



Actual results:

a touch keyboard shows up.


Expected results:

it shouldn't call a taptip.exe, because ui.osk.enabled is disabled.

as it looks like only happens at firefox 42 beta, (it isn't in firefox 43 dev edition and 44 nightly) I think this bug is DOA. but it would better if this bug fixed in 42b4

Comment 1

[:Gijs (he/him)]

I don't think that this is Firefox explicitly calling taptip, unless the compiler has so seriously mangled our code there that reasoning about the C++ is useless. AFAICT we consistently check the pref everywhere. So I expect that we are somehow managing to convince windows that it should show the keyboard some other way. While it'd be good to figure out why that is, I don't know that we can/should necessarily fix it... depends on how it's being triggered.

Comment 2

[:Gijs (he/him)]

So I have confirmed with debugging that this is not us firing up tabtip. That said, it is also not clear to me why Windows is firing it up. Jim, do you have any ideas? Mostly I'm just curious if we could rip out our hacks and use whatever is causing this to happen for the password field to do the same for other input fields.

Comment 3

[Jim Mathies [:jimm]]

Maybe I'm missing something here:

testing on nightly + win10, visit the hotmail login page and tap the password field, nothing happens.

I tried with true and false set for ui.osk.enabled, and I tried in tablet mode and out of tablet mode.

Comment 4

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #3)
> Maybe I'm missing something here:
> 
> testing on nightly + win10, visit the hotmail login page and tap the
> password field, nothing happens.
> 
> I tried with true and false set for ui.osk.enabled, and I tried in tablet
> mode and out of tablet mode.

er, sorry, with ui.osk.enabled set to true and in tablet mode, the keyboard comes up, but this is expected.

Comment 5

[:Gijs (he/him)]

(In reply to Jim Mathies [:jimm] from comment #4)
> (In reply to Jim Mathies [:jimm] from comment #3)
> > Maybe I'm missing something here:
> > 
> > testing on nightly + win10, visit the hotmail login page and tap the
> > password field, nothing happens.
> > 
> > I tried with true and false set for ui.osk.enabled, and I tried in tablet
> > mode and out of tablet mode.
> 
> er, sorry, with ui.osk.enabled set to true and in tablet mode, the keyboard
> comes up, but this is expected.

So on my surface pro 3, with the keyboard not attached, and in win10 tablet mode, *and* with the pref set to false, I get the popup keyboard. Are you saying you're seeing different results with some other device without a physical keyboard?

Comment 6

[Jim Mathies [:jimm]]

That's correct. I just checked again on the bugzilla password login input, same behavior. Surface Pro 2, whatever rev of windows 10 that's currently publicly available. No keyboard or with a bluetooth keyboard attached.

Comment 7

[Jim Mathies [:jimm]]

Note I'm tapping on the touch screen, not using a mouse.

Comment 8

[Jim Mathies [:jimm]]

Try setting accessibility.force_disable to true, restart, and see if it goes away.

Comment 9

[Jim Mathies [:jimm]]

another one: intl.tsf.enable

Comment 10

[:Gijs (he/him)]

(In reply to Jim Mathies [:jimm] from comment #8)
> Try setting accessibility.force_disable to true, restart, and see if it goes
> away.

This seems to be triggering this. If I set this to 1, it goes away. Maybe that means you can reproduce if you set it to -1 ?

Still really curious what that ends up meaning...

Comment 11

[Jim Mathies [:jimm]]

(In reply to :Gijs Kruitbosch from comment #10)
> (In reply to Jim Mathies [:jimm] from comment #8)
> > Try setting accessibility.force_disable to true, restart, and see if it goes
> > away.
> 
> This seems to be triggering this. If I set this to 1, it goes away. Maybe
> that means you can reproduce if you set it to -1 ?
> 
> Still really curious what that ends up meaning...

Yeah that is weird since I don't see it in a similar setup. When I was working on metrofx, we had a lite implementation of UIA for text inputs. Windows would query this for information immediately after a tap and if we returned the correct information from various UIA calls, the soft keyboard would display. 

My guess is that for some reason Windows is coming in and querying for info similar to what it did for metrofx via the accessibility interfaces we support in desktop (IAccessible/IAccessibleEx). But this isn't supposed to happen in desktop apps, that's why you had to do all that crazy stuff stuff with  taptip.exe. We could dump some a11y logging to see what calls are being made maybe if our a11y library supports it.

A couple questions:

1) Is there any chance you've flipped some weird Windows pref here to get this working?
2) This only happens for password fields??

Comment 12

[:Gijs (he/him)]

(In reply to Jim Mathies [:jimm] from comment #11)
> (In reply to :Gijs Kruitbosch from comment #10)
> > (In reply to Jim Mathies [:jimm] from comment #8)
> > > Try setting accessibility.force_disable to true, restart, and see if it goes
> > > away.
> > 
> > This seems to be triggering this. If I set this to 1, it goes away. Maybe
> > that means you can reproduce if you set it to -1 ?
> > 
> > Still really curious what that ends up meaning...
> 
> Yeah that is weird since I don't see it in a similar setup. When I was
> working on metrofx, we had a lite implementation of UIA for text inputs.
> Windows would query this for information immediately after a tap and if we
> returned the correct information from various UIA calls, the soft keyboard
> would display. 
> 
> My guess is that for some reason Windows is coming in and querying for info
> similar to what it did for metrofx via the accessibility interfaces we
> support in desktop (IAccessible/IAccessibleEx). But this isn't supposed to
> happen in desktop apps, that's why you had to do all that crazy stuff stuff
> with  taptip.exe. We could dump some a11y logging to see what calls are
> being made maybe if our a11y library supports it.

Surkov, any suggestions about what to poke at to get such a log?

> A couple questions:
> 
> 1) Is there any chance you've flipped some weird Windows pref here to get
> this working?

There's a win10 pref to get the touch keyboard to show up in desktop mode as well as tablet mode. That's flipped. Sounds like that could potentially explain this (does that help you repro?)? Still strange though...

> 2) This only happens for password fields??

Yes. This is the weirdest part. I tried other input types listed in the IME handler code (<input type="url"> and such) but I haven't found anything else that does this.

Comment 13

[alexander :surkov (:asurkov)]

(In reply to :Gijs Kruitbosch from comment #12)

> > My guess is that for some reason Windows is coming in and querying for info
> > similar to what it did for metrofx via the accessibility interfaces we
> > support in desktop (IAccessible/IAccessibleEx). But this isn't supposed to
> > happen in desktop apps, that's why you had to do all that crazy stuff stuff
> > with  taptip.exe. We could dump some a11y logging to see what calls are
> > being made maybe if our a11y library supports it.
> 
> Surkov, any suggestions about what to poke at to get such a log?

there's no ready hooks to use to dump what a11y methods were called but you can always introduce them as you need. IAccessible is implemented by AccessibleWrap class, IAccessibleEx is implemented by uiaRawElmProvider class.

Comment 14

[Vasilica Tamas, QA [:vtamas]]

The on-screen keyboard is displayed when a password field is focused even with ui.osk.enabled set to false only under the following conditions:
 [1] Tablet Mode enabled
 [2] e10s - disabled (For Nightly and Aurora)


Tested across Firefox 45.0a1 (2015-11-04), Firefox 44.0a2 (2015-11-04) and Firefox 43 beta 1 build 2 under Windows 10 64-bit using a Dell XPS 12 with hardware keyboard and a Surface Pro 2 with no keyboard attached.

Comment 15

[Jim Mathies [:jimm]]

I can't really add much here about a11y. some manual debugging on a system that reproduces seems best.

Comment 16

[Kartikaya Gupta (email:[e-mail])]

I can repro this on Nightly with e10s disabled. e10s enabled works fine.

Comment 17

[:Gijs (he/him)]

Tracy, I noticed you looked at bug 1228298 as well, is this one still current on the new win10 builds?

Comment 18

[Tracy Walker [:tracy]]

I see "with ui.osk.enabled set to true and in tablet mode, the keyboard comes up, but this is expected."

Some clear STR's with whatever prefs/options need to be set at to reproduce would be helpful.

Comment 19

[:Gijs (he/him)]

(In reply to Tracy Walker [:tracy] from comment #18)
> I see "with ui.osk.enabled set to true and in tablet mode, the keyboard
> comes up, but this is expected."
> 
> Some clear STR's with whatever prefs/options need to be set at to reproduce
> would be helpful.

The main issue seems to be turning off e10s and the ui.osk.enabled pref, and using a touch-enabled device.

Vasilica, can you help, as you reproduced in the past?

Comment 20

[Tracy Walker [:tracy]]

STR's

0) may not be necessary, but I had accepted to always remember choice of tablet mode when the physical keyboard is attached/detached (corresponding to tablet mode disabled/enabled)
1) Detach physical keyboard to put device into tablet mode
2) set about:config UI.OSK.enabled to false
3) ensure about:config browser.tabs.remote.force-enable is false  (user may have set it to true to use e10s+a11y)
4) open bugzilla (or another site, requiring login, that you're not actively logged in at)
5) touch the password field


tested result:
The OSK appears
5a) touch the awesomebar field and note no OSK appears

expected results:
no OSK appears

Note this doesn't happen in e10s (which you have to set about:config browser.tabs.remote.force-enable to true). They OSK doesn't appear when touching the password field.

Comment 21

[Tracy Walker [:tracy]]

Actually, with STR's above, you'll get stuck with no ability to type into URL bar.

This is a better order:

0) may not be necessary, but I had accepted to always remember choice of tablet mode when the physical keyboard is attached/detached (corresponding to tablet mode disabled/enabled)
1) set about:config UI.OSK.enabled to false
2) ensure about:config browser.tabs.remote.force-enable is false  (user may have set it to true to use e10s+a11y)
3) open bugzilla (or another site, requiring login, that you're not actively logged in at)
4) Detach physical keyboard to put device into tablet mode
5) touch the password field

Comment 22

[Kartikaya Gupta (email:[e-mail])]

I suspect this bug is basically a WONTFIX. It's more likely that we'll ship e10s everywhere and decommission the non-e10s builds before we get around to fixing this.