Closed Bug 1226145 Opened 4 years ago Closed 4 years ago

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

Categories

(Core :: Widget: Win32, defect)

x86_64
Windows 10
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla46
Tracking Status
firefox44 --- affected
firefox45 --- verified
firefox46 --- verified
firefox47 --- verified

People

(Reporter: vasilica.mihasca, Assigned: Gijs)

References

Details

Attachments

(1 file)

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)
It's probably not worth filing a separate issue for the google docs case for now, no.
Flags: needinfo?(gijskruitbosch+bugs)
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)
(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)
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)
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)
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+
https://hg.mozilla.org/mozilla-central/rev/b13cc636c9c8
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Blocks: 1243345
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
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
You need to log in before you can comment on or make changes to this bug.