Closed Bug 1162680 Opened 4 years ago Closed 4 years ago

[Contacts] Hitting the X (back/cancel) while loading the Gmail/Outlook import contacts sign-in will cause the keyboard to become stuck on the screen

Categories

(Core :: DOM: Device Interfaces, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla41
Tracking Status
firefox41 --- fixed
b2g-v2.1 --- unaffected
b2g-v2.2 --- wontfix
b2g-master --- verified

People

(Reporter: jmitchell, Assigned: rudyl)

References

()

Details

(Whiteboard: [3.0-Daily-Testing])

Attachments

(7 files, 2 obsolete files)

Description:
During the import contacts process, if the user selects X to cancel the process and dismiss the screen while the keyboard is coming up, they keyboard will become stuck on the screen. The user will be back on the Import Contacts page with the keyboard up but there is no text entry on this page. Hitting the keys does nothing, and long pressing the spacebar to dismiss the keyboard has no effect. User can then navigate the contacts app with the keyboard stuck on the screen. Issue will dismiss by hitting the home button and returning to the app. 


Repro Steps:
1) Update a Flame to 20150507064907
2) Launch Contacts
3) Select Settings
4) Select Import Contacts
5) Select Outlook
6) As the keyboard comes up from the bottom of the screen hit the X button (timing sensitive)


Actual:
Keyboard becomes stuck on the screen


Expected:
keyboard will dismiss


Environmental Variables:
Device: Flame 3.0
Build ID: 20150507064907
Gaia: 83b27f522642ea573c57e882657ab5c73d4b07f4
Gecko: 403e3c2380b5
Gonk: a9f3f8fb8b0844724de32426b7bcc4e6dc4fa2ed
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0



Repro frequency: 7/40
See attached: logcat, video clip: http://youtu.be/Ct82b7u9Rwk
I was able to reproduce this issue in Flame KK 2.2 at a lower rate (2/40) and was not able to reproduce in 2.1 (0/50). Not sure if that should be considered a regression though, just a failure to reproduce, so leaving that keyword off. 

Device: Flame 2.2 (KK - Nidghtly - Full Flash - 319mem)
Build ID: 20150506002501
Gaia: 772a9491909abd02dc67278dd453746e2dd358a8
Gecko: 3af6a0a79227
Gonk: ab265fb203390c70b8f2a054f38cf4b2f2dad70a
Version: 37.0 (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 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150506001242
Gaia: b4a03b7ee61de5a479b3cf0916f47e91a43b0f50
Gecko: 4493015380ab
Gonk: ab265fb203390c70b8f2a054f38cf4b2f2dad70a
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
I think this problem cannot be solved in contacts, since we are doing a window.open and don't have control over the new window and the keyboard.

Alive do you think this is something related to window management? Or perhaps keyboard?
Flags: needinfo?(alive)
Looks like input management bug to me
Component: Gaia::Contacts → Gaia::System::Input Mgmt
Flags: needinfo?(alive) → needinfo?(timdream)
Rudy could you take this? If not I will take it on Monday.
Assignee: nobody → rlu
Status: NEW → ASSIGNED
blocking-b2g: --- → 2.2+
Flags: needinfo?(timdream) → needinfo?(rlu)
I cannot reproduce this with "Import with Outlook" as "Microsoft accounts" cannot function per my test.
However, I could reproduce the same symptom with Gmail option, so I'll try to investigate this issue.
Flags: needinfo?(rlu)
Per my investigation, this issue occurs when Gecko did not send "inputmethod-contextchange" mozChromeEvent to notify that the input field is blurred.
 see: https://github.com/mozilla-b2g/gaia/blob/52942e1be3aa1146d555edbd28b862f896e666ed/apps/system/js/keyboard_manager.js#L217

So, I'll change the component accordingly.
Component: Gaia::System::Input Mgmt → DOM: Device Interfaces
Product: Firefox OS → Core
After checking, Keyboard.jsm won't get 'Forms:Input' (for blur) event for this case,
http://lxr.mozilla.org/mozilla-central/source/dom/inputmethod/Keyboard.jsm#196

So the problem should be in form.js.
I will continue to look into that.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
In this case, forms.js would send blur event at the end, but system app would not get it, will investigate the root cause.
For case 1, this should be resolved by Bug 1162360, so I'll just set dependency to it.
However, I still could reproduce this issue (with much lower repro rate, per my test)
by applying the patch in Bug 1162360, and it turns out to be the same as case 2, i.e. we would send "blur" event to Keyboard.jsm, but Keyboard.jsm does not get this.

Maybe this is because the frame is closed soon, but I am not sure.
Will try to open IPC debug log to see what we would do here.
Depends on: 1162360
Attached file ipc debug log
This is the log I collected with IPC debug log enabled,
|MOZ_IPC_MESSAGE_LOG=1 b2g.sh|

Will need to consult some experts to diagnose this.
As we might need some time to dig into the IPC debug log and find out where we should look into, could QA help find the regression window so that we could narrow down the search scope?

I could not reproduce on v2.1 per my own test, so if possible please help identify the regression window on v2.2.

Thanks.
Per my own testing, I found this is much easier to reproduce on master than v2.2, so we probably could find regression window on master?
The repro rate for this issue drops too severely to get a reliable window.  It took me 28 attempts to reproduce on the build below.  Any regression window found would be pure guesswork on whether something was actually a working build or broken.

Device: Flame 3.0
BuildID: 20150430105749
Gaia: 759a1f935a6a81c32ad66e39a6353b334dfa4f91
Gecko: 7723b15ea695
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
From my test, it turns out we could reproduce this with a much higher rate (should repro when trying < 10 times), because of Bug 1143226's landing.
That patch changes the animation duration of many (if not all) UI components in gaia, and might cause the frame of login page destroyed much faster than before.

I would like to re-nominate this as v2.2, since that patch lands on master only to gain more time for us to dig into the root cause.
blocking-b2g: 2.2+ → 2.2?
Attached file debug_log_TabParent
Add some logs into TabParent, but still not sure why Keyboard.jsm could not get the message as we did invoke manager->ReceiveMessage().
Attached file log_messageMgr_close
From this line we can see that the messageManager is closed before it can send out the blur message to Keyboard.jsm.

I think this is the root cause, will try to intercept the message "message-manager-close" in Keyboard.jsm to see if this can fix this issue.

===
06-02 07:38:32.530: I/Gecko(8158): in nsFrameMessageManager::Close 0xaa2dc040
...
...
06-02 07:38:32.770: I/Gecko(8158): in nsFrameMessageManager::ReceiveMessage 0xaa2dc040 - Forms:Input
This is the first attempt trying to fix this issue, that we would listen to message-manager-close event in Keyboard.jsm, and send the blur event when the blur has not been issued yet.

Tim, could you please give feedback on this patch?
I went through a few bugs around Keyboard.jsm, but it seems not that easy to add tests for Keyboard.jsm?

Thanks.
Attachment #8614638 - Flags: feedback?(timdream)
Comment on attachment 8614638 [details] [diff] [review]
0001-Bug-1162680-Notify-Keyboard.jsm-to-send-blur-event-w.patch

Let's simply set formMM to null when the blur message is valid?
Attachment #8614638 - Flags: feedback?(timdream) → feedback+
Attached patch Patch v1.1 (obsolete) — Splinter Review
Patch updated per the review comments.

Tim, could you help review this or we need to find another reviewer?
Thanks.
Attachment #8614638 - Attachment is obsolete: true
Attachment #8615839 - Flags: review?(timdream)
Comment on attachment 8615839 [details] [diff] [review]
Patch v1.1

According to offline conversation w/ :smaug and :masayuki I can review this, but maybe not.

Please make sure we have a green try run before landing.
Attachment #8615839 - Flags: review?(timdream) → review+
Attached patch Patch v1.2Splinter Review
Add the reviewer info, carry forward r+.
Attachment #8615839 - Attachment is obsolete: true
Attachment #8621478 - Flags: review+
We have a green try run here, so ask for check-in.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=92b7062ee240

I am going to open a follow-up for adding the mochitest.
Keywords: checkin-needed
Depends on: 1174096
https://hg.mozilla.org/mozilla-central/rev/a79fc7f1c37d
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Mark 2.2 wontfix as this is not blocking 2.2 CC.
This issue is verified fixed on Flame. Following STR, the keyboard does not stay on screen after hitting X as it comes up. Repro rate: 0 out of ~50.

Device: Flame (KK, full flashed, 319MB)
BuildID: 20150617010205
Gaia: 6271f932e1e918a35ee89f54288bd13385143a71
Gecko: d7c148c84594
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 41.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
blocking-b2g: 2.2? → ---
Depends on: 1152699
You need to log in before you can comment on or make changes to this bug.