1250484 - [e10s] The OSK hides and reappears when switching focus between 2 textareas on some machines

Status: NEW

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

Description

[Vasilica Tamas, QA [:vtamas]]

[Note]:
This is a follow-up for Bug 1226148

[Affected versions]:
Firefox 47.0a1 (2016-02-22)
Firefox 46.0a2 (2016-02-23)

[Affected platforms]:
Windows 10 64-bit

[Prerequisites]:
Navigate a bit on Firefox 45 Beta 8.

[Steps to reproduce]:
1.Launch Firefox with clean profile.
2.Navigate to https://login.yahoo.com/
3.Type your username using OSK.
4.Tap the password field. (or select the OSK Tab key in order to focus the password field)


[Expected Results]:
The OSK remains displayed.

[Actual Results]:
The OSK closes and reappears.


[Additional notes]:
- This issue is not reproducible if the first tested browser after opening the device is Firefox 47.0a1 or Firefox 46.0a2.
- It only reproduces after navigating a bit on Firefox 45 beta 8.
- To be noticed that both profiles, Firefox 45 beta 8 and Firefox 47.0a1 are opened with clean and separate profiles.
- This issue is not reproducible on Surface Pro 2: http://i.imgur.com/3QXZEo6.png
- I encountered this bug only on Dell Xps 12. about:config values are the same when this issue is reproducible or not: http://i.imgur.com/3ZF8Spv.png

Comment 1

[Vasilica Tamas, QA [:vtamas]]

Forgot to mention that a browser restart fixes this issue.

Comment 2

[Tracy Walker [:tracy]]

Vasilica, I don't have the hardware you're reproducing this on. Does it still reproduce with latest Nightly?

Comment 3

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

I investigated this issue on Dell Xps 12, using accounts.google.com and login.yahoo.com on Windows 10 Home Insider Preview x64.

On latest Nightly 51.0a1 (2016-08-16) and latest Aurora 50.0a2 (2016-08-17), after typing in a text field and then
- tapping the next text field, the OSK closes and reappears -> the bug is still reproducible
- selecting the OSK Tab key in order to focus the next text field, the OSK closes and doesn't reappear just after tapping again a text field.
After restart, the result is the expected one.

On 48.0.1 build1 (20160816033124), 49.0b4 build1 (20160814184416)(where e10s is disabled by default) and on Google Chrome, in the same two above cases, the OSK remains displayed.

Comment 4

[:Gijs (he/him)]

(In reply to Iulia Cristescu, QA [:IuliaC] from comment #3)
> I investigated this issue on Dell Xps 12, using accounts.google.com and
> login.yahoo.com on Windows 10 Home Insider Preview x64.

I'm guessing one of these input fields is a password field, and those are "special".

Can you try on e.g. bugzilla input fields in a bug, or a more straightforward HTML testcase that just has two inputs or textarea fields?

> On 48.0.1 build1 (20160816033124), 49.0b4 build1 (20160814184416)(where e10s
> is disabled by default) and on Google Chrome, in the same two above cases,
> the OSK remains displayed.

So are you saying this is e10s-specific?

Comment 5

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

Attachment: text area testcase.html

Comment 6

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

(In reply to :Gijs Kruitbosch (PTO recovery mode) from comment #4)
> (In reply to Iulia Cristescu, QA [:IuliaC] from comment #3)
> > I investigated this issue on Dell Xps 12, using accounts.google.com and
> > login.yahoo.com on Windows 10 Home Insider Preview x64.
> 
> I'm guessing one of these input fields is a password field, and those are
> "special".
> 
> Can you try on e.g. bugzilla input fields in a bug, or a more
> straightforward HTML testcase that just has two inputs or textarea fields?
> 
I also tried using bugzilla input fields and a simple HTML file (attachment 8782363 [details]) -> the result is the same.
 
> > On 48.0.1 build1 (20160816033124), 49.0b4 build1 (20160814184416)(where e10s
> > is disabled by default) and on Google Chrome, in the same two above cases,
> > the OSK remains displayed.
> 
> So are you saying this is e10s-specific?

Yes, this issue is e10s-specific.
I have to complete comment 3 by adding that latest Nightly (2016-08-17), latest Aurora (2016-08-17), 48.0.1 build1 (20160816033124)and 49.0b4 build1 (20160814184416) are affected only when e10s is on. I didn't manage to properly investigate this previously, because when I tried to trigger e10s,  about:support was indicating that e10s is disabled by accessibility reasons. Now I managed to force it by creating a new boolean pref named browser.tabs.remote.force-enable and settting it to true.

Comment 7

[Tracy Walker [:tracy]]

This is still reproducible with latest Nightly 53.0a1, 20161116030212

Using the attached test case, swapping focus back and forth between the two text fields, always slides the OSK closed then back open, in e10s.  With e10s turned off, when swapping focus back and forth the OSK remains open.