1226145 - On-screen keyboard not re-displayed when tapping a focused field when the keyboard has been manually closed by the user

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect)

Description

[Vasilica Tamas, QA [:vtamas]]

Note: this is a follow-up for Bug 1221947
Reproducible on: Firefox 45.0a1 and Firefox 44.0a2 using Windows 

Prerequisites: Tabled mode enabled

STR
1.Launch Firefox with a clean profile.
2.Open a new tab (click “+” button). (url bar is already focused)
3.Tap on url bar.

ER
The OSK is successfully displayed.

AR
The OSK is not displayed. It appears only after the field is unfocused and focused again.
- This issue is also reproducible for: about:config search field, home page search field, yahoo username field from https://login.yahoo.com/


Additional notes:
- This issue is reproducible on Firefox 45.0a1 (2015-11-18) and Firefox 44.0a2 under Windows 10 64-bit.
- This testing was performed on a Dell Xps 12 with tabled mode enabled.

Comment 1

[Vasilica Tamas, QA [:vtamas]]

I think the same issue reproduces on an online Google document ( https://goo.gl/sPqJWb ). The osk is not displayed because the document is already focused. Am I right? Or this is another issue and should be tracked separately?

Comment 2

[:Gijs (he/him)]

It's probably not worth filing a separate issue for the google docs case for now, no.

Comment 3

[:Gijs (he/him)]

I think this should now be fixed on Nightly and 45 by bug 1224605. Vasilica, can you confirm this?

Comment 4

[Vasilica Tamas, QA [:vtamas]]

(In reply to :Gijs Kruitbosch (away 18-28 Dec.) from comment #3)
> I think this should now be fixed on Nightly and 45 by bug 1224605. Vasilica,
> can you confirm this?

This bug seems to be fixed on Firefox 46.0a1 (2015-12-15) following the steps from Description, but noticed a potential issue:
1.Open a new tab 
2.Tap on url bar.
3.Close the OSK by clicking “X” button.
4.Tap again on url bar.

The osk is not displayed.


And besides this, the osk still not appears for google docs.

Comment 5

[:Gijs (he/him)]

(In reply to Vasilica Mihasca, QA [:vasilica_mihasca] from comment #4)
> (In reply to :Gijs Kruitbosch (away 18-28 Dec.) from comment #3)
> > I think this should now be fixed on Nightly and 45 by bug 1224605. Vasilica,
> > can you confirm this?
> 
> This bug seems to be fixed on Firefox 46.0a1 (2015-12-15) following the
> steps from Description, but noticed a potential issue:
> 1.Open a new tab 
> 2.Tap on url bar.
> 3.Close the OSK by clicking “X” button.
> 4.Tap again on url bar.
> 
> The osk is not displayed.

OK. Let's fix that in this bug.

> And besides this, the osk still not appears for google docs.

OK. I'm surprised they get treated differently, and I'll have to investigate that separately. Can you file a new issue for the google docs case, please?

Comment 6

[Vasilica Tamas, QA [:vtamas]]

(In reply to :Gijs Kruitbosch (away 18-28 Dec.) from comment #5)

> OK. I'm surprised they get treated differently, and I'll have to investigate
> that separately. Can you file a new issue for the google docs case, please?

Filed Bug 1233006

Comment 7

[:Gijs (he/him)]

Attachment: MozReview Request: Bug 1226145 - actually check whether the on-screen keyboard is up rather than relying on internal state, r?masayuki

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

Comment 8

[:Gijs (he/him)]

Jared, I'm not sure why we're using the internal bool to keep track of things... can you doublecheck this is sane?

Comment 9

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

Comment on attachment 8698931 [details]
MozReview Request: Bug 1226145 - actually check whether the on-screen keyboard is up rather than relying on internal state, r?masayuki

https://reviewboard.mozilla.org/r/28129/#review25189

::: widget/windows/WinIMEHandler.cpp
(Diff revision 1)
> -      sShowingOnScreenKeyboard ||

Checking this just seemed like a "good idea" as it doesn't make sense to show it if it is already showing.

My question is, do we know why this variable is getting out of date? If we want to remove this check here, should we remove this variable altogether?

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 8698931 [details]
MozReview Request: Bug 1226145 - actually check whether the on-screen keyboard is up rather than relying on internal state, r?masayuki

https://reviewboard.mozilla.org/r/28129/#review25193

::: widget/windows/WinIMEHandler.cpp
(Diff revision 1)
> -      sShowingOnScreenKeyboard ||

I think so. sShowingOnScreenKeyboard isn't modified when the OSK is closed not by us. So, checking sShowingOnScreenKeyboard should be replaced with checking the result of GetOnScreenKeyboardWindow().

So, I think that sShowingOnScreenKeyboard should be removed.

Comment 11

[:Gijs (he/him)]

Comment on attachment 8698931 [details]
MozReview Request: Bug 1226145 - actually check whether the on-screen keyboard is up rather than relying on internal state, r?masayuki

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/28129/diff/1-2/

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 8698931 [details]
MozReview Request: Bug 1226145 - actually check whether the on-screen keyboard is up rather than relying on internal state, r?masayuki

https://reviewboard.mozilla.org/r/28129/#review25197

Looks good to me.

Comment 13

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/b13cc636c9c8

Comment 14

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

Comment on attachment 8698931 [details]
MozReview Request: Bug 1226145 - actually check whether the on-screen keyboard is up rather than relying on internal state, r?masayuki

https://reviewboard.mozilla.org/r/28129/#review25201

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/b13cc636c9c8

Comment 16

[:Gijs (he/him)]

Comment on attachment 8698931 [details]
MozReview Request: Bug 1226145 - actually check whether the on-screen keyboard is up rather than relying on internal state, r?masayuki

Approval Request Comment
[Feature/regressing bug #]: Windows on-screen keyboard support
[User impact if declined]: the keyboard is sometimes not shown when it should be shown
[Describe test coverage new/current, TreeHerder]: no. However, extra manual QA was done, and no regressions that stop us shipping this on 45 were found.
[Risks and why]: reasonably low, this has baked for a while and was already verified
[String/UUID change made/needed]: no

Comment 17

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8698931 [details]
MozReview Request: Bug 1226145 - actually check whether the on-screen keyboard is up rather than relying on internal state, r?masayuki

Improve the windows 10 support, taking it.

Comment 18

[Sylvestre Ledru [:Sylvestre]]

Should be in 45 beta 5

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/9d7cf5811a0b

Comment 20

[Vasilica Tamas, QA [:vtamas]]

I was able to reproduce this issue on Firefox 45.0a1 (2015-11-19) under Windows 10 64-bit.

Verified fixed on Firefox 47.0a1 (2016-02-21), Firefox 46.0a2 (2016-02-22) and Firefox 45 beta 8 (20160218171844) under Windows 10 64-bit using 2 devices: Dell Xps 12 and Surface Pro 2.