1238892 - Disable on-screen keyboard support for Windows 8 on Firefox 44

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect)

Description

[:Gijs (he/him)]

Because of issues described in bug 1236058 and others, we'd like to disable the on-screen keyboard support for Windows 8 (and 8.1). It will continue working on Windows 10.

Release Note Request (optional, but appreciated)
[Why is this notable]: We relnoted the feature for 43
[Suggested wording]: On-screen keyboard support was temporarily turned off for Windows 8 and Windows 8.1.
[Links (documentation, blog post, etc)]: n/a?

Let me know if this needs more detailed information.

Comment 1

[:Gijs (he/him)]

Attachment: disable on-screen-keyboard support for Windows 8(.1),

Comment 2

[:Gijs (he/him)]

Comment on attachment 8706910 [details] [diff] [review]
disable on-screen-keyboard support for Windows 8(.1),

Approval Request Comment
[Feature/regressing bug #]: on-screen keyboard support doesn't seem polished enough to ship on win8(.1)
[User impact if declined]: bug 1236058 and friends
[Describe test coverage new/current, TreeHerder]: nope
[Risks and why]: very low, toggling a feature off just for win8 (not win10) using a pre-existing pref.
[String/UUID change made/needed]: no

Comment 3

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Gijs, in general, it's a good idea to not ship features if they are not at the expected quality. However in this case, did we have this enabled in Fx43? And will some win8 users be left wondering why their on-screen keyboard suddenly stopped working? If yes, this might be worth relnoting somehow. Thoughts?

Comment 4

[:Gijs (he/him)]

(In reply to Ritu Kothari (:ritu) from comment #3)
> Hi Gijs, in general, it's a good idea to not ship features if they are not
> at the expected quality. However in this case, did we have this enabled in
> Fx43?

Yes.

> And will some win8 users be left wondering why their on-screen
> keyboard suddenly stopped working?

Potentially yes.
> If yes, this might be worth relnoting somehow. Thoughts?

Yes, that's why I relnote?'d in comment #0. Did I miss something I need to do for that?

Comment 5

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(In reply to :Gijs Kruitbosch from comment #4)
> (In reply to Ritu Kothari (:ritu) from comment #3)
> > Hi Gijs, in general, it's a good idea to not ship features if they are not
> > at the expected quality. However in this case, did we have this enabled in
> > Fx43?
> 
> Yes.
> 
> > And will some win8 users be left wondering why their on-screen
> > keyboard suddenly stopped working?
> 
> Potentially yes.
> > If yes, this might be worth relnoting somehow. Thoughts?
> 
> Yes, that's why I relnote?'d in comment #0. Did I miss something I need to
> do for that?

My bad, missed reading the description. Let's do it then! :)

Comment 6

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8706910 [details] [diff] [review]
disable on-screen-keyboard support for Windows 8(.1),

We will relnote this in Fx44 release notes and turning this feature off on win8 versions as it needs more fit-and-finish. Beta44+

Comment 7

[Justin Dolske [:Dolske]]

Before we do this, do we have any data to understand the tradeoffs of unshipping vs not? I'm guessing not, but a skim of recent bugzilla/input/SUMO issues might yield something?

It looks like 1007063 rode the 43 train without any early uplift, and after all that time in pre-release and during the 43 release (albeit over the holidays), it seems like we have just 1 user report of this not working?

I don't want to ignore a small-signal that indicates an unexpected problem, but a backout could be worse than the bug here.

Comment 8

[:Gijs (he/him)]

(In reply to Justin Dolske [:Dolske] from comment #7)
> Before we do this, do we have any data to understand the tradeoffs of
> unshipping vs not? I'm guessing not, but a skim of recent
> bugzilla/input/SUMO issues might yield something?

I can try to look at input/SUMO tomorrow. For SUMO: Rachel, do you know what kind of (if any) SUMO questions arose for the 43 release relating to the on-screen keyboard on Windows 8/8.1 ?

> It looks like 1007063 rode the 43 train without any early uplift, and after
> all that time in pre-release and during the 43 release (albeit over the
> holidays), it seems like we have just 1 user report of this not working?
> 
> I don't want to ignore a small-signal that indicates an unexpected problem,
> but a backout could be worse than the bug here.

bug 1236058 was technically more than one user, but yeah. Note also that 1007063 was disabled by default until we changed that in bug 1217806. That was uplifted for aurora, the day before aurora went to beta. So it essentially "just" had a beta cycle, from that perspective.

The reason Jared and I think/thought it made sense to disable for 44 is in part related to how Windows 8 tablet behaviour is not really well-defined by the OS to begin with. Win10 has reasonable user-control by way of "tablet mode" in its own UI. By default on win10, Firefox won't show the OSK in desktop mode. On win8, there's obviously "modern" apps, but we don't run in that mode at all. Classic apps, like notepad, don't do anything with the OSK. That leads to kludgy things for users (bug 1236058 describes using 2 pdf viewers in the touch-friendly and non-touch friendly modes of the OS).

We now switched from never showing an OSK (which to a certain degree is expected because we're a "classic" app) to always showing it if we thought it was appropriate. On top of that, pre bug 1236058 we weren't aware of *any* circumstances where we showed the OSK when we shouldn't do so. The combination of both of those factors (no OS-side way of controlling the behaviour, and us always showing the keyboard with no way to opt-out, making using Firefox very very painful) makes me think we should turn it off for win8. We can leave it on for Win10, and we'll turn win8 back on once we have the bluetooth case figured out and/or decide more generally if we want to tweak things for win8.

It's true that we might be turning it off for users where it is currently working perfectly well. We don't have conclusive data for how prevalent the bluetooth case is compared to others. It's likely it's a minority, but OTOH, the failure consequences of not showing the keyboard when the user would like to vs. always showing it when the user doesn't want us to are pretty different in terms of impact...

Does that make more sense? Do you think this is the wrong call?

Comment 9

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #8)
> (In reply to Justin Dolske [:Dolske] from comment #7)
> > Before we do this, do we have any data to understand the tradeoffs of
> > unshipping vs not? I'm guessing not, but a skim of recent
> > bugzilla/input/SUMO issues might yield something?

Looking from 43 launch date (dec. 15) to today, for win8.1 only, searching for "keyboard"

https://input.mozilla.org/en-US/?q=keyboard&date_end=2016-01-13&date_start=2015-12-15&product=Firefox&platform=Windows%208.1

is something like 80% complaints about the keyboard showing when it shouldn't (10 out of 13 items). There is nobody who is happy with the feature working the way it's designed. Looking at Windows 10, instead there are people who complain that the keyboard doesn't have predictive text or URL (".com" key) support, or that it doesn't pop up when it should - but nobody saying that it's annoying or pops up when it shouldn't.

Comment 10

[Justin Dolske [:Dolske]]

Ok, thanks, that makes sense to me. Didn't bake as long as I thought, and the feedback seems to confirm this is affecting more users.

Also sounds like between this being a bit of a surprise and Windows 8 having wonky support, that it's plausible this could be hard to get right, and we might just never fix it for Windows 8? In which case it would be better to unship it early, and let the (diminishing) number of users who use Windows 8 with tablets flip the pref to enable it if it's working for their particular setup.

Ship it!

Comment 11

[:Gijs (he/him)]

remote:   https://hg.mozilla.org/releases/mozilla-beta/rev/bdb6dcb5477b

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/bdb6dcb5477b

Comment 13

[Vasilica Tamas, QA [:vtamas]]

I confirm that the on-screen keyboard is no longer displayed in Firefox 44 Beta 9 (20160114165817) under Windows 8.1 64-bit, but the ui.osk.enabled pref is still set to true. Shouldn't be set to false?

Comment 14

[:Gijs (he/him)]

(In reply to Vasilica Mihasca, QA [:vasilica_mihasca] from comment #13)
> I confirm that the on-screen keyboard is no longer displayed in Firefox 44
> Beta 9 (20160114165817) under Windows 8.1 64-bit, but the ui.osk.enabled
> pref is still set to true. Shouldn't be set to false?

No, we flipped a different pref (ui.osk.require_win10) to true. This is expected.

Comment 15

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Added to Fx44 release notes.

Comment 16

[:Gijs (he/him)]

Jared, should we keep this on until 46 (ie land this on 45 as well) because 46 is the first with a user-visible pref (and hopefully, bug 1239744)?

Comment 17

[Jared Wein [:jaws] (please needinfo? me)]

Yeah, let's uplift this to 45 since we don't have the user-visible pref there.