1288219 - Virtual keyboard not displaying when touching address bar or text fields when detaching the tablet/screen from surfacebook

Status: RESOLVED DUPLICATE of bug 1648534

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

Description

[Peter Dolanjski [:pdol]]

Microsoft Surfacebook, Windows 10 Pro
Firefox 47.0.1
ui.osk.debug.keyboardDisplayReason = AIOSKIDM: failed reading value of regkey

Steps to reproduce:
- Launch Firefox
- Disconnect screen from hardware keyboard
- Touch address bar, search field or text field on webpage

Expected Result:
- Focus is placed in field 
- Virtual keyboard displays

Actual Result: 
- Focus is placed in field 
- No virtual keyboard displays

Comment 1

[:Gijs (he/him)]

So, some questions:

- if you open the action center (the icon next to the clock that looks like a speech bubble), is the setting labeled "tablet mode" active when you have detached the screen like this? If you activate it if it isn't already, does that make things work (and if so, does it stop working once you deactivate tablet mode)?

- in regedit, in HKEY_CURRENT_USER\SOFTWARE\Microsoft\TabletTip\1.7, is there a setting EnableDesktopModeAutoInvoke present or not?

- are you using an insider build or regular release?

- can you locate this setting: http://www.windowscentral.com/auto-display-touch-keyboard-windows-10-desktop-mode and if you see it, does toggling it on/off fix this bug?

Comment 2

[:Gijs (he/him)]

Jared, should the win10 desktop mode thing happen only for non-touch accesses? I think so... (ie, if you touch to focus, we should show the osk even in desktop mode, I think - even if we checked for keyboards that'd be better behaviour than this...)

Comment 3

[Peter Dolanjski [:pdol]]

>>if you open the action center (the icon next to the clock that looks like a speech bubble), is the setting labeled "tablet mode" active when you have detached the screen like this? If you activate it if it isn't already, does that make things work (and if so, does it stop working once you deactivate tablet mode)?

My device was NOT in tablet mode.  When I active tablet mode, touching in a field does indeed bring up the virtual keyboard.  It also stops working when I deactivate tablet mode.

A point to note: I'm using the default settings for this device (which is to not enable tablet mode when you disconnect the keyboard).

>>in regedit, in HKEY_CURRENT_USER\SOFTWARE\Microsoft\TabletTip\1.7, is there a setting EnableDesktopModeAutoInvoke present or not?

It is NOT present.

>>are you using an insider build or regular release?

Regular release

>>can you locate this setting: http://www.windowscentral.com/auto-display-touch-keyboard-windows-10-desktop-mode and if you see it, does toggling it on/off fix this bug?

This setting was already set to ON.  I toggled it off and then back on and now the problem is fixed.

Comment 4

[Peter Dolanjski [:pdol]]

Do we have a way to determine how widespread this issue might be? (vs. being limited to this particular device)

Comment 5

[:Gijs (he/him)]

(In reply to Peter Dolanjski [:pdol] from comment #4)
> Do we have a way to determine how widespread this issue might be? (vs. being
> limited to this particular device)

Not that I'm aware of.

Based on your input and what I remember from early builds of win10, MS must have toggled the default value of that registry key (which corresponds to the option you changed in the settings app) either in the Win10 release update or the initial release (we worked with insider builds before release to get Firefox into shape).

It feels like we should just update the code to assume the default is 'yes, use touch on desktop', and people who don't want that can obviously toggle the option in question off.

Comment 6

[Peter Dolanjski [:pdol]]

> It feels like we should just update the code to assume the default is 'yes, use touch on desktop', and 
> people who don't want that can obviously toggle the option in question off.

That feels like the safest bet, but I am worried that this might be a widespread problem on release channel for these types of devices (which are starting to get very common).

Comment 7

[:Gijs (he/him)]

(In reply to Peter Dolanjski [:pdol] from comment #6)
> > It feels like we should just update the code to assume the default is 'yes, use touch on desktop', and 
> > people who don't want that can obviously toggle the option in question off.
> 
> That feels like the safest bet, but I am worried that this might be a
> widespread problem on release channel for these types of devices (which are
> starting to get very common).

I'm not sure about "very common": https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2016-06-23&keys=__none__!__none__!__none__&max_channel_version=release%252F47&measure=TOUCH_ENABLED_DEVICE&min_channel_version=null&os=Windows_NT%252C10.0&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-06-04&table=0&trim=1&use_submission_date=0

suggests only 7.4% of release devices using windows 10 support touch.

Even if it were, not sure what you're implying - just saying we should prioritize this highly? Something else?

Comment 8

[Peter Dolanjski [:pdol]]

(In reply to :Gijs Kruitbosch from comment #7)
> suggests only 7.4% of release devices using windows 10 support touch.
> 
> Even if it were, not sure what you're implying - just saying we should
> prioritize this highly? Something else?

Good to know the data, thanks.  

What I mean is that maybe we need to patch the release version (unless that's what you meant to do). (7.4% of Win10 users is still millions of people)

Comment 9

[:Gijs (he/him)]

(In reply to Peter Dolanjski [:pdol] from comment #8)
> (In reply to :Gijs Kruitbosch from comment #7)
> > suggests only 7.4% of release devices using windows 10 support touch.
> > 
> > Even if it were, not sure what you're implying - just saying we should
> > prioritize this highly? Something else?
> 
> Good to know the data, thanks.  
> 
> What I mean is that maybe we need to patch the release version (unless
> that's what you meant to do). (7.4% of Win10 users is still millions of
> people)

7.4% of the Firefox users on Windows 10, which telemetry says is about 2.25 million samples over the last month or so (likely significantly fewer individuals/machines). You're also assuming they're all running into this, which is unlikely, or we would have seen more duplicates filed. We've had issues with the on-screen keyboard before on windows 8, and sentiment on input.m.o was much stronger. Right now I can barely find 2 bits of feedback from windows 10 users (who are more numerous than win8 ones) on input.m.o over the last month, relating to the on-screen keyboard. So I don't think that being too worried is warranted. :-)

We only really patch release for critical security/stability/functionality issues, and we're 2-3 weeks away from a new release. So I don't think we will fix 47. We can try for 48, but even that I'm not sure we'll make. I'll see if I can patch something today.

Comment 10

[:Gijs (he/him)]

Attachment: Bug 1288219 - flip default assumptions for desktop-mode auto-invocation of touch keyboard,

Review commit: https://reviewboard.mozilla.org/r/66076/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/66076/

Comment 11

[Justin Dolske [:Dolske]]

Is this a regression, or did it just never work

Comment 12

[:Gijs (he/him)]

(In reply to Justin Dolske [:Dolske] from comment #11)
> Is this a regression, or did it just never work

I expect it used to work on older Windows builds, but I haven't checked.

Comment 13

[Peter Dolanjski [:pdol]]

(In reply to :Gijs Kruitbosch from comment #9)
> 7.4% of the Firefox users on Windows 10, which telemetry says is about 2.25
> million samples over the last month or so (likely significantly fewer
> individuals/machines). You're also assuming they're all running into this,
> which is unlikely, or we would have seen more duplicates filed. We've had
> issues with the on-screen keyboard before on windows 8, and sentiment on
> input.m.o was much stronger. Right now I can barely find 2 bits of feedback
> from windows 10 users (who are more numerous than win8 ones) on input.m.o
> over the last month, relating to the on-screen keyboard. So I don't think
> that being too worried is warranted. :-)

I did some digging as well (input.mozilla.org and general web searches for the issue.  I'm not seeing evidence that it is very prevalent.

Comment 14

[Justin Dolske [:Dolske]]

So, I'm a little confused.

I can reproduce this on my Surface Pro with an insider build that's just a few weeks old. The Win10 settings Devices -> Typing -> "Show touch keyboard when not in tablet mode and no keyboard attached" pref is off for me (and I'm fairly sure I've never touched it), and the EnableDesktopModeAutoInvoke registry key is missing (thus triggering this bug). Edge and Chrome act the same way we do.

So if we ignore Peter for a moment, I don't see any sign that MS changed anything here. Unless Insider builds have a different default? (Which would seem weird.) Do we have any indication (from other users/installs) that Peter's system represents the new norm? If it's not, that would explain the lack of other reports...

Part of my hesitancy here is that I don't understand why MS made this the default -- seems pretty stupid to not automatically bring up the soft keyboard when there's no hardware keyboard available. But maybe I'm missing something?

Comment 15

[Justin Dolske [:Dolske]]

(Just to be clear -- the existing behavior is _correct_ on my system, so fixing this bug would make Firefox act differently from other apps.)

Comment 16

[:Gijs (he/him)]

(In reply to Justin Dolske [:Dolske] from comment #14)
> So, I'm a little confused.
> 
> I can reproduce this on my Surface Pro with an insider build that's just a
> few weeks old. The Win10 settings Devices -> Typing -> "Show touch keyboard
> when not in tablet mode and no keyboard attached" pref is off for me (and
> I'm fairly sure I've never touched it), and the EnableDesktopModeAutoInvoke
> registry key is missing (thus triggering this bug). Edge and Chrome act the
> same way we do.
> 
> So if we ignore Peter for a moment, I don't see any sign that MS changed
> anything here. Unless Insider builds have a different default? (Which would
> seem weird.) Do we have any indication (from other users/installs) that
> Peter's system represents the new norm? If it's not, that would explain the
> lack of other reports...
> 
> Part of my hesitancy here is that I don't understand why MS made this the
> default -- seems pretty stupid to not automatically bring up the soft
> keyboard when there's no hardware keyboard available. But maybe I'm missing
> something?

Something odd is going on here. Because the same thing happened in bug 1261252. The reporter basically experienced the same thing as Peter, and Jared did what you just did, Dolske, and reported the same thing (missing registry key, pref is off).

I don't know if the default is different on "regular" releases vs. insider builds, but that seems like the most plausible explanation I can think of at this stage. It'd be useful if Peter tried the "create a new windows account, check registry + settings app" sequence to see if he gets something different from you + Jared...

Comment 17

[Peter Dolanjski [:pdol]]

I just received this Surfacebook and set it up fresh a few days ago.  I didn't change any default hardware settings.  

> The Win10 settings Devices -> Typing -> "Show touch keyboard when not in tablet mode and no keyboard 
> attached" pref is off for me

The interesting part is that my pref was on prior to me touching anything.  Toggling off and then back on (to the state it was already in) fixed the issue.

I just created a new account to try again.  There is no registry entry for EnableDesktopModeAutoInvoke.  Under Settings > Devices > Typing > "Show the touch keyboard or handwriting panel when not in tablet mode and there's no keyboard attached" is set to ON.

Without changing anything, all other software (eg. Edge) works fine and brings up the virtual keyboard.  Firefox doesn't work.  Then when I toggle the "show the touch keyboard..." setting OFF and then back ON, it starts working.  

It is entirely possible that this is a limited issue with this machine.

To get specific this is Windows 10 Pro version 1511, OS build 10586.494.

Comment 18

[Peter Dolanjski [:pdol]]

I just had Asa and Dave Camp try this on their Surfacebook's.  Asa had his "show the touch keyboard..." set to OFF by default.  Turning it ON caused it to work.  Dave's seems to be working normally.

So, this boils down to my "show the touch keyboard..." setting being ON by default but Firefox not actually using that pref state for some reason.

Comment 19

[Justin Dolske [:Dolske]]

Jared's suggestion was that we might need to check an additional registry key, which sounds on the right track to me... It sounds like the registry may not always have a default value (ie, it's missing), while manually twiddling with the pref causes it to actually be stored. We just need to make sure we somehow pick the right behavior when the registry entry is missing.

Comment 20

[:Gijs (he/him)]

I'm not going to be around for the next 2 weeks, and comment #19 means this needs more detailed investigation, so unassigning for now.

Comment 21

[Justin Dolske [:Dolske]]

Comment on attachment 8773342 [details]
Bug 1288219 - flip default assumptions for desktop-mode auto-invocation of touch keyboard,

https://reviewboard.mozilla.org/r/66076/#review63072

r- until we figure out how to do the right thing everywhere. (Or at least understand why the defaults differ.)

::: widget/windows/WinIMEHandler.cpp:863
(Diff revision 1)
>    uint32_t value;
>    rv = regKey->ReadIntValue(NS_LITERAL_STRING("EnableDesktopModeAutoInvoke"),
>                              &value);
>    if (NS_FAILED(rv)) {
>      Preferences::SetString(kOskDebugReason,
>                             L"AIOSKIDM: failed reading value of regkey.");

Do you want to add an "assuming true" to the debug message here too?

Comment 22

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 23

[Daniel Bodea [:danibodea]]

I am seeing this issue on a Lenovo Yoga C630, but the behavior of the Windows’ on-screen-keyboard still feels a bit confusing/unreliable and I believe I found the cause: I think that the OS and/or the browser needs a restart after modifying any OS related settings (specifically the System/Tablet mode settings and the Typing/Touch keyboard/"Show touch keyboard when not in tablet mode and no keyboard attached" pref) in order for the browser reliably take the settings made and apply them correctly.
What I mean to say is that these issues seem to occur right after modifying settings or modifying the position (or disconnection, in the case of the Surface) of the physical keyboard (tablet/desktop modes).
I don’t know whether I can investigate this issue even further or not. This argument also points to the possibility that this issue is OS related and cannot be fixed from browser side unless there’s a way to force the browser to take the OS settings in the current browser/OS session. Am I speaking nonsense?
Do you think I should continue to investigate this issue? If yes, then how?

Furthermore, this issue is strongly related to the use of Windows touch devices/implementation of the aarch64 build, so I think that this may elevate the issue's priority.

I can test reproduction of this issue on Lenovo Yoga and Microsoft Surface Pro, but I need pointers.
Thanks.

Comment 24

[Jim Mathies [:jimm]]

(In reply to Bodea Daniel [:danibodea] from comment #23)

I am seeing this issue on a Lenovo Yoga C630, but the behavior of the
Windows’ on-screen-keyboard still feels a bit confusing/unreliable and I
believe I found the cause: I think that the OS and/or the browser needs a
restart after modifying any OS related settings (specifically the
System/Tablet mode settings and the Typing/Touch keyboard/"Show touch
keyboard when not in tablet mode and no keyboard attached" pref) in order
for the browser reliably take the settings made and apply them correctly.
What I mean to say is that these issues seem to occur right after modifying
settings or modifying the position (or disconnection, in the case of the
Surface) of the physical keyboard (tablet/desktop modes).
I don’t know whether I can investigate this issue even further or not. This
argument also points to the possibility that this issue is OS related and
cannot be fixed from browser side unless there’s a way to force the browser
to take the OS settings in the current browser/OS session. Am I speaking
nonsense?
Do you think I should continue to investigate this issue? If yes, then how?

Furthermore, this issue is strongly related to the use of Windows touch
devices/implementation of the aarch64 build, so I think that this may
elevate the issue's priority.

I can test reproduction of this issue on Lenovo Yoga and Microsoft Surface
Pro, but I need pointers.
Thanks.

Detailed STR would be helpful so we can prioritize. This bug has been around for a while and we have very few dupes, so it doesn't seem that serious.

Comment 25

[Chuck Harmston [:chuck]]

Andrew, is this the same thing you observed and reported to Microsoft?

Comment 26

[Daniel Bodea [:danibodea]]

Andrew, can you please attach the report to made to Microsoft here so I can check whether it covers what I was planning to report myself? Thank you.

Comment 27

[Andrew Overholt [:overholt]]

I submitted an issue related to the wifi not reconnecting: https://aka.ms/AA4ebg3

Comment 28

[Daniel Bodea [:danibodea]]

Oh, I thought it might have been related to this issue.
I have also logged one for the virtual not extending reliably: https://aka.ms/AA4kx7t

Comment 29

[Markus S.]

Oh wow, 4 years and still unfixed. Just got a brand new Surface Pro 7. Didn't own a touchscreen PC before.

Works fine in Chromium Edge, btw.

Comment 30

[Bence Bálint]

Just encountered this issue on a Surface Go, a few weeks ago the on-screen keyboard stopped working in Firefox. I got the missing registry key, managed to recover with the help of this thread (went to windows settings, disabled and re-enabled the setting, and the registry key popped up), so just mentioning that Windows still falls apart on this one sometimes.

Currently, the behavior on the missing registry key seems to be an error in Firefox, which results in the keyboard not showing. In other apps, when there is no key in the registry, they default to true and do show the keyboard -- why not replicate that in Firefox?

Comment 31

[:Gijs (he/him)]

(In reply to Bence Bálint from comment #30)

Just encountered this issue on a Surface Go, a few weeks ago the on-screen keyboard stopped working in Firefox. I got the missing registry key, managed to recover with the help of this thread (went to windows settings, disabled and re-enabled the setting, and the registry key popped up), so just mentioning that Windows still falls apart on this one sometimes.

Currently, the behavior on the missing registry key seems to be an error in Firefox, which results in the keyboard not showing. In other apps, when there is no key in the registry, they default to true and do show the keyboard -- why not replicate that in Firefox?

I think you've found the wrong bug. If you noticed a recent regression, it sounds like that might have been caused by bug 1648534 or related issues.

What version did you notice the issue with? Firefox 80? If so, does Firefox 79 behave correctly? (You could test by temporarily removing the registry key, I expect...)

:masayuki or :m_kato, should this be duped forward given the recent comments and the comments in bug 1648534?

Comment 32

[Bence Bálint]

(In reply to :Gijs (he/him) from comment #31)

I think you've found the wrong bug. If you noticed a recent regression, it sounds like that might have been caused by bug 1648534 or related issues.

What version did you notice the issue with? Firefox 80? If so, does Firefox 79 behave correctly? (You could test by temporarily removing the registry key, I expect...)

You're right, I was on Firefox 79, updating to Firefox 80 fixed it. I've tried removing the registry key manually and even then it detected it as true in about:config (ui.osk.debug.keyboardDisplayReason was "AIOSKIDM: regkey value=true", while in the past it showed an error).

Comment 33

[:Gijs (he/him)]

OK, I'm going to assume bug 1648534 fixed the issue then. Thank you!