1123240 - Keyboard triggered by closing activity with disposition: window may still be displayed on the app that triggered the activity after the activity closes (this case: contacts triggering email)

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::System::Input Mgmt, defect)

Description

[Shally Li（leave from Mozilla）]

[1.Description]:
[Flame][v2.2][Contacts]Sometimes the soft keyboard will pop up on contact view page after user tap on email box and then tap Cancel button.
Attch:logcat_1450.txt and keyboard.MP4.
Test fille:2015_1_19_7.vcf.
Found time:14:50

[2.Testing Steps]: 
1.Launch Contacts.
2.Open the contact’s email to view.
3.Tap on email box.
4.Tap on Cancel button on Confirmation page.

[3.Expected Result]: 
4.Soft keyboard should not pop up.

[4.Actual Result]: 
4.Soft keyboard will pop up on contact detail page.

[5.Reproduction build]: 
Flame v2.1 build:
Gaia-Rev        77c57eb8a985d5cbd34a597fb1b978ba6e205af6
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/452a023ae7b2
Build-ID        20150118001331
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150118.034742
FW-Date         Sun Jan 18 03:47:53 EST 2015
Bootloader      L1TC000118D0

Flame 2.2 build:
Gaia-Rev        f5b3d1b6cfa3e702033f613915ae637cb735cbfb
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/8067c111ddff
Build-ID        20150118002501
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150118.035516
FW-Date         Sun Jan 18 03:55:27 EST 2015
Bootloader      L1TC000118D0

[6.Reproduction Frequency]: 
occasionally Recurrence,5/10

[7.TCID]: 
Free Test

Comment 1

[Shally Li（leave from Mozilla）]

Attachment: logcat_1450.txt

Comment 2

[Shally Li（leave from Mozilla）]

Attachment: 2015_1_19_7.vcf

Comment 3

[Shally Li（leave from Mozilla）]

Attachment: logcat_1450.txt

Comment 4

[Shally Li（leave from Mozilla）]

Attachment: keyboard.MP4

Comment 5

[Johan Lorenzo [:jlorenzo]]

[Blocking Requested - why for this release]: Regression that happened in 2.2.

Comment 6

[William Hsu [:whsu]]

Hi, Shally,

Can it be reproduced on v2.0?
Thanks.

Comment 7

[Jose Manuel Cantera]

As per my investigations this seems to be something related to the email app. Could it be that the confirm dialog card

Comment 8

[Jose Manuel Cantera]

Attachment: GH PR

Comment 9

[William Hsu [:whsu]]

(In reply to Jose Manuel Cantera from comment #7)
> As per my investigations this seems to be something related to the email
> app. Could it be that the confirm dialog card

Thanks for Jose's proactive help!

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8551247 [details] [review]
GH PR

This looks like a window manager/keyboard bug and this pull request is just working around the problem.  Specifically, I believe the email app is explicitly focusing an input field on the setup_account_info card as its activity is being hidden.

Whatever system logic is in charge of the keyboard is getting tricked by this.  Even if the sequence of events is: [(focus), (get notification activity is going away)], I would presume the system/keyboard logic should revisit the desired keyboard state once it gets the notification that the activity is going away.

I would suggest this bug be moved to the system/keyboard component.  I'm needinfo-ing James Burke who owns the e-mail UI/front-end and this specific code to see if he has thoughts on whether the "return" is or is not the right thing for us to be doing in general, and/or if there's an acceptable mitigation for this system bug.  (In particular, I would probably be happy with a comment on the return that explained what the implications of that return are on the state of the email app given that we're not explicitly triggering a window.close() at that point, and so there could be some weird state build-up.)

Comment 11

[Andrew Sutherland [:asuth] (he/him)]

Oh, oops, I see this bug did get moved to the email component already.  So now I'm moving it to the keyboard-y one.

Comment 12

[Jose Manuel Cantera]

(In reply to Andrew Sutherland [:asuth] from comment #10)
> Comment on attachment 8551247 [details] [review]
> GH PR
> 
> This looks like a window manager/keyboard bug and this pull request is just
> working around the problem.  Specifically, I believe the email app is
> explicitly focusing an input field on the setup_account_info card as its
> activity is being hidden.

Yes, and what's the point in doing so if the user does not want to continue as he has decided not to enter any account details and the activity has posted an error? 

> 
> Whatever system logic is in charge of the keyboard is getting tricked by
> this.  Even if the sequence of events is: [(focus), (get notification
> activity is going away)], I would presume the system/keyboard logic should
> revisit the desired keyboard state once it gets the notification that the
> activity is going away.
> 
> I would suggest this bug be moved to the system/keyboard component. 

I disagree. The email app has a weird behavior that tricks the keyboard app and causes collateral effects. 

 I'm
> needinfo-ing James Burke who owns the e-mail UI/front-end and this specific
> code to see if he has thoughts on whether the "return" is or is not the
> right thing for us to be doing in general, and/or if there's an acceptable
> mitigation for this system bug.  (In particular, I would probably be happy
> with a comment on the return that explained what the implications of that
> return are on the state of the email app given that we're not explicitly
> triggering a window.close() at that point, and so there could be some weird
> state build-up.)

I will await for James response here, since as you say, perhaps not only do we need a return but other clean up instructions.

Comment 13

[howie [:howie]]

Triage: regression, blocking. regression window wanted ,thanks

Comment 14

[James Burke [:jrburke]]

This seems like something the Keyboard app should try to prevent -- other apps could trigger a similar situation based on async data flow and the timing of user interactions. Email just happened to have triggered one of these cases.

For example, an app could start to show a header area with a back button that would `activity.postError('cancelled');` when tapped. It has body content, but needs to wait on network resources before showing the body of the UI, and once the network activity finished, it would input.focus() on a form element in that body.

If the user taps the back button before the network activity completes, it would lead to a similar behavior in the Keyboard.

As for the email-specific pull request, it is not a complete fix:

* User taps on email address in contacts.
* Mail app opens, and pushes a Compose card. This is done speculatively since the usual case for the email app is to have an account configured, and we want the UI to start up quickly. Then, email gets the results from the async data query that determines the user does not have any account, and shows the "Create account?" dialog.
* User taps Cancel.

If the return is done after calling postError, email is left in a bad state: Email is still running in the background, so if the user long presses on the Home button and goes back to email, then the UI is still at the Compose card. However, since the user does not have an account, this is non-functional UI and the app is stuck.

The other work done in mail_app's promptEmptyAccount() function resets state and the UI to avoid that from happening, so an early return is not advisable there.

Trying to prevent this issue on the email side would be a bigger change, and I do not think it is an appropriate thing to mitigate within an app. In general, trying to code an app to be aware of secondary effects by other system features is usually undesirable. 

Sometimes those in-app workarounds are needed due to time constraints or more appropriate changes taking longer, but it would be good to have the Keyboard team run this down a bit before going down that path.

Comment 15

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I was able to reproduce this issue on 2.2 builds from a few days ago, but was not able to reproduce on today's 2.2 or any 3.0 build.  Leaving the tags for now in case someone else can reproduce this on today's build..

Issue DOES reproduce:

Device: Flame 2.2
BuildID: 20150117032800
Gaia: f5b3d1b6cfa3e702033f613915ae637cb735cbfb
Gecko: 8067c111ddff
Version: 37.0a2 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Issue does NOT reproduce:

Environmental Variables:
Device: Flame 3.0
BuildID: 20150120032136
Gaia: 579e01ad4d6e4177a8f636305ac877835d99f134
Gecko: c2df1daf74c3
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Device: Flame 2.2
BuildID: 20150119184939
Gaia: f5b3d1b6cfa3e702033f613915ae637cb735cbfb
Gecko: 5d7497ce4cc7
Version: 37.0a2 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 16

[Joshua Mitchell (Inactive)]

I can confirm that these do not reproduce on today's builds for 2.2, 2.1 and 2.0

Actual Results: I would see the keyboard pop up momentarily but go away VERY quickly (1/3 times) - or not pop up at all (2/3 times). 

Device: Flame 3.0 (nightly - KK - Full Flashed)
Build ID: 20150120010227
Gaia: a5c5ac093814a80b0627514c3bd5f9e96c096a4b
Gecko: c1c6840d9255
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Device: Flame 2.2
Build ID: 20150120002507 (nightly - KK - Full Flashed)
Gaia: f5b3d1b6cfa3e702033f613915ae637cb735cbfb
Gecko: 5d7497ce4cc7
Gonk: Could not pull gonk.  Did you shallow Flash?
Version: 37.0a2 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 2.1 (nightly - KK - Full Flashed)
Build ID: 20150120001202
Gaia: 77c57eb8a985d5cbd34a597fb1b978ba6e205af6
Gecko: f05d0a2d2378
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
-------------------------------------------------------------------------------------------

removing regression-window wanted keyword as it does not seem necessary anymore - would recommend closing as WFM as this is now fixed in the latest builds.

Comment 17

[Joshua Mitchell (Inactive)]

Edit

*I can confirm that these do not reproduce on today's builds for 3.0, 2.2 and 2.1 



(my kingdom for an edit button)

Comment 18

[KTucker [:KTucker][Inactive 3/4/2016]]

Closing as worksforme based upon the information in comment 17.

Comment 19

[Shally Li（leave from Mozilla）]

Hi Joshua,

    I can repro this bug on Today's Flame v2.2 build. Please refer again,thanks.
    Please see attahcments:2015_1_20_3.vcf,verifyFail_0919.mp4 and logcat_0919.txt.
    Rate:5/5.

Flame 2.2 build:
Gaia-Rev        f5b3d1b6cfa3e702033f613915ae637cb735cbfb
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/5d7497ce4cc7
Build-ID        20150120002507
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150120.035540
FW-Date         Tue Jan 20 03:55:51 EST 2015
Bootloader      L1TC000118D0

Comment 20

[Shally Li（leave from Mozilla）]

Attachment: logcat_0919.txt

Comment 21

[Shally Li（leave from Mozilla）]

Attachment: 2015_1_20_3.vcf

Comment 22

[Shally Li（leave from Mozilla）]

Attachment: verifyFail_0919.mp4

Comment 23

[Shally Li（leave from Mozilla）]

Hi All,

    I find the same problem that soft keyboard will pop up when user tap Cancel button in Gallery app (Video app/Music app/Browser app) on Flame v2.2.
    Please see gallery_v2.2.MP4 and logcat_gallery_1653.txt.
    Rate:3/3.

Comment 24

[Shally Li（leave from Mozilla）]

Attachment: logcat_gallery_1653.txt

Comment 25

[Shally Li（leave from Mozilla）]

Attachment: gallery_v2.2.MP4

Comment 26

[Shally Li（leave from Mozilla）]

Attachment: gallery_v2.2.MP4

Comment 27

[Shally Li（leave from Mozilla）]

Attachment: gallery_v2.2_.MP4

Comment 28

[Noemí Freire (:noemi)]

Attachment: Flamev3.0_From_Contacts

I am also able to reproduce it on today's (1/21) master build. Environmental variables:
Flame 3.0 device
BuildId: 20150121064527
Gecko: dc6b716
Gaia: 1c91c05
Platform version: 38.0a1

Comment 29

[Noemí Freire (:noemi)]

Because of comments 19-28 reopening this bug till clarifying which is the failing scenario. Thanks!

Comment 30

[Joshua Mitchell (Inactive)]

I'm still not able to reproduce the keyboard coming up permanently, only temporarily. 
Additionally - when looking at the video from comment 27 - did anyone else notice that the header for the email app is not correct (timeframe 11 and 12sec). This bug seems like a symptom of that bug (bug of a bug) because it does not repro (at least for me) unless the header is also incorrect. The correct header of email would have the search bar the smaller size in the upper left corner and a < on the left side of the "Compose" bar. This seems like there is a larger bug dealing with transiting (back and forth) between apps breaking the headers. Not sure if there is one in for that or not.

Comment 31

[Kai-Chih Hu [:khu]]

I tried the latest 2.2 build, and I can reproduce it rarely(around 5%?). But, whenever I reproduced it, I found that the keyboard showed but then it was closed quickly. I am not sure if it's proper to set this bug as a blocker.

Comment 32

[howie [:howie]]

resolved works for me based on comment 30 31