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

VERIFIED FIXED in Firefox 45

Status

()

VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: vasilica.mihasca, Assigned: Gijs)

Tracking

Trunk
mozilla46
x86_64
Windows 10
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox44 affected, firefox45 verified, firefox46 verified, firefox47 verified)

Details

Attachments

(1 attachment)

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.
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?
Flags: needinfo?(gijskruitbosch+bugs)
(Assignee)

Comment 2

3 years ago
It's probably not worth filing a separate issue for the google docs case for now, no.
Flags: needinfo?(gijskruitbosch+bugs)
(Assignee)

Comment 3

3 years ago
I think this should now be fixed on Nightly and 45 by bug 1224605. Vasilica, can you confirm this?
No longer blocks: 1221947
Depends on: 1224605
Flags: needinfo?(vasilica.mihasca)
(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.
Flags: needinfo?(vasilica.mihasca)
(Assignee)

Comment 5

3 years ago
(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?
Flags: needinfo?(vasilica.mihasca)
Summary: On-screen keyboard not displayed for an already focused text field → On-screen keyboard not re-displayed when tapping a focused field when the keyboard has been manually closed by the user
(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
Flags: needinfo?(vasilica.mihasca)
(Assignee)

Comment 7

3 years ago
Created 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 commit: https://reviewboard.mozilla.org/r/28129/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/28129/
Attachment #8698931 - Flags: review?(masayuki)
Attachment #8698931 - Flags: review?(jaws)
(Assignee)

Comment 8

3 years ago
Jared, I'm not sure why we're using the internal bool to keep track of things... can you doublecheck this is sane?
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
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?
Attachment #8698931 - Flags: review?(jaws)
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.
Attachment #8698931 - Flags: review?(masayuki)
(Assignee)

Comment 11

3 years ago
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/
Attachment #8698931 - Attachment description: MozReview Request: Bug 1226145 - actually check whether the on-screen keyboard is up rather than relying on internal state, r?jaws,masayuki → MozReview Request: Bug 1226145 - actually check whether the on-screen keyboard is up rather than relying on internal state, r?masayuki
Attachment #8698931 - Flags: review?(masayuki)
Attachment #8698931 - Flags: review?(masayuki) → review+
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 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
Attachment #8698931 - Flags: review+

Comment 15

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/b13cc636c9c8
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox46: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
(Assignee)

Updated

3 years ago
Blocks: 1243345
(Assignee)

Comment 16

3 years ago
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
Attachment #8698931 - Flags: approval-mozilla-beta?
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.
Attachment #8698931 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Should be in 45 beta 5

Comment 19

3 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/9d7cf5811a0b
status-firefox45: affected → fixed
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.
Status: RESOLVED → VERIFIED
status-firefox45: fixed → verified
status-firefox46: fixed → verified
status-firefox47: --- → verified
You need to log in before you can comment on or make changes to this bug.