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)

RESOLVED WORKSFORME

Status

Firefox OS
Gaia::System::Input Mgmt
RESOLVED WORKSFORME
3 years ago
3 years ago

People

(Reporter: Shally Li(leave from Mozilla), Assigned: Jose Manuel Cantera)

Tracking

({regression})

unspecified
ARM
Gonk (Firefox OS)
regression

Firefox Tracking Flags

(blocking-b2g:-, b2g-v2.1 unaffected, b2g-v2.2 affected, b2g-master affected)

Details

Attachments

(10 attachments, 3 obsolete attachments)

(Reporter)

Description

3 years ago
[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
(Reporter)

Comment 1

3 years ago
Created attachment 8551160 [details]
logcat_1450.txt
(Reporter)

Comment 2

3 years ago
Created attachment 8551161 [details]
2015_1_19_7.vcf
(Reporter)

Comment 3

3 years ago
Created attachment 8551162 [details]
logcat_1450.txt
(Reporter)

Comment 4

3 years ago
Created attachment 8551171 [details]
keyboard.MP4
(Reporter)

Updated

3 years ago
Attachment #8551162 - Attachment is obsolete: true
[Blocking Requested - why for this release]: Regression that happened in 2.2.
blocking-b2g: --- → -
Keywords: regression
blocking-b2g: - → 2.2?

Updated

3 years ago
status-b2g-master: --- → affected

Comment 6

3 years ago
Hi, Shally,

Can it be reproduced on v2.0?
Thanks.
Flags: needinfo?(lixia)
(Assignee)

Comment 7

3 years ago
As per my investigations this seems to be something related to the email app. Could it be that the confirm dialog card
(Assignee)

Updated

3 years ago
Component: Gaia::Contacts → Gaia::E-Mail
(Assignee)

Updated

3 years ago
Assignee: nobody → jmcf
(Assignee)

Comment 8

3 years ago
Created attachment 8551247 [details] [review]
GH PR
Attachment #8551247 - Flags: review?(bugmail)

Comment 9

3 years ago
(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!
Flags: needinfo?(lixia)
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.)
Flags: needinfo?(jrburke)
Attachment #8551247 - Flags: review?(bugmail)
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.
Component: Gaia::E-Mail → Gaia::System::Input Mgmt
Summary: [Flame][Contacts]Sometimes the soft keyboard will pop up on contact detail page. → 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)
(Assignee)

Comment 12

3 years ago
(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

3 years ago
Triage: regression, blocking. regression window wanted ,thanks
blocking-b2g: 2.2? → 2.2+
Keywords: regressionwindow-wanted
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.
Flags: needinfo?(jrburke)
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
QA Contact: jmercado
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Contact: jmercado
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.
Keywords: regressionwindow-wanted
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)
Closing as worksforme based upon the information in comment 17.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(ktucker)
Resolution: --- → WORKSFORME
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
(Reporter)

Comment 19

3 years ago
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
Flags: needinfo?(jmitchell)
(Reporter)

Comment 20

3 years ago
Created attachment 8552167 [details]
logcat_0919.txt
(Reporter)

Comment 21

3 years ago
Created attachment 8552168 [details]
2015_1_20_3.vcf
(Reporter)

Comment 22

3 years ago
Created attachment 8552169 [details]
verifyFail_0919.mp4
(Reporter)

Comment 23

3 years ago
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.
(Reporter)

Comment 24

3 years ago
Created attachment 8552303 [details]
logcat_gallery_1653.txt
(Reporter)

Comment 25

3 years ago
Created attachment 8552308 [details]
gallery_v2.2.MP4
(Reporter)

Comment 26

3 years ago
Created attachment 8552328 [details]
gallery_v2.2.MP4
(Reporter)

Updated

3 years ago
Attachment #8552308 - Attachment is obsolete: true
(Reporter)

Updated

3 years ago
Attachment #8552328 - Attachment is obsolete: true
(Reporter)

Comment 27

3 years ago
Created attachment 8552330 [details]
gallery_v2.2_.MP4
Created attachment 8552379 [details]
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
Because of comments 19-28 reopening this bug till clarifying which is the failing scenario. Thanks!
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
Flags: needinfo?(jmitchell)

Comment 31

3 years ago
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.
blocking-b2g: 2.2+ → 2.2?

Comment 32

3 years ago
resolved works for me based on comment 30 31
Status: REOPENED → RESOLVED
blocking-b2g: 2.2? → -
Last Resolved: 3 years ago3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.