859596 - Input focus didn't be taken away when the window is closed by parent.

Status: VERIFIED FIXED

(Firefox OS Graveyard :: General, defect, P2)

Description

[leo.bugzilla.gecko]

Step : 
  1) Go to BT settings and search for a BT mono headset (I use LG HBM-220)
  2) Try to pair with it, it should require PIN code: 0000
  3) If successfully paired and connected try to unpair and perform again 1-2 steps. Observe the UI behaviour (see attached video)

Detailed Symptom : 
  Sometimes on the screen remains PIN code numeric keyboard (see video) and there are problems with BT headset pairing procedure.

Expected :
  There shouldn't be any problems while pairing.

I'll Show attach a video file.
Please, check the issue.

Comment 1

[leo.bugzilla.gecko]

Attachment: keypad is showed always

Comment 2

[Evelyn Hung]

From the video, at the time point 2:49, a pairing screen shows and then quickly covered by a connection fail(?) screen, that's why keypad sticks on the screen because the pairing screen wasn't closed correctly. 

Shawn, do we have this kind of device for test? or can you reproduce the issue on another headset?

Comment 3

[Dylan Oliver [:doliver]]

This issue was identified as a Leo QE1 blocker. Nominating for leo?

Comment 4

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

This issue was not related to Bluetooth. It is related to window management, I guess. I will let Evelyn comment on.

Comment 5

[Evelyn Hung]

(In reply to Shawn Huang from comment #4)
> This issue was not related to Bluetooth. It is related to window management,
> I guess. I will let Evelyn comment on.

I investigated the problem before, and believe it's not related to Bluetooth module.
The problem is: if a window with input field focused is closed by its parent, the input focus didn't be released (i.e. keyboard app won't get a blur event).
We may need someone looking into frame script (form.js) to know why the focus change didn't happen.

Comment 6

[Shelly Lin [:shelly]]

Attachment: Patch

Hi Evelyn, could u review my patch, thanks!

Comment 7

[Shelly Lin [:shelly]]

Attachment: Patch

Comment 8

[Shelly Lin [:shelly]]

Btw, if you stay idle on the paring screen with keyboard shown, wait until the device locks the screen itself. If unlock the screen again, will observe that the top half of paring screen draws over the unlock screen.

Sounds like another bug?

Comment 10

[Evelyn Hung]

(In reply to Shelly Lin [:shelly] from comment #8)
> Btw, if you stay idle on the paring screen with keyboard shown, wait until
> the device locks the screen itself. If unlock the screen again, will observe
> that the top half of paring screen draws over the unlock screen.
> 
> Sounds like another bug?
Yes, sounds another bug not related to this issue. Could you file another bug with detailed STR? Thanks you. 

(In reply to Shelly Lin [:shelly] from comment #6)
> Created attachment 742241 [details] [diff] [review]
> Patch
> 
> Hi Evelyn, could u review my patch, thanks!
I'll try this on Monday, I need a entering-pin bluetooth device for test.

Comment 11

[Shelly Lin [:shelly]]

(In reply to Evelyn Hung [:evelyn] from comment #10)
> (In reply to Shelly Lin [:shelly] from comment #8)
> > Btw, if you stay idle on the paring screen with keyboard shown, wait until
> > the device locks the screen itself. If unlock the screen again, will observe
> > that the top half of paring screen draws over the unlock screen.
> > 
> > Sounds like another bug?
> Yes, sounds another bug not related to this issue. Could you file another
> bug with detailed STR? Thanks you. 
> 
> (In reply to Shelly Lin [:shelly] from comment #6)
> > Created attachment 742241 [details] [diff] [review]
> > Patch
> > 
> > Hi Evelyn, could u review my patch, thanks!
> I'll try this on Monday, I need a entering-pin bluetooth device for test.

Thanks Evelyn :), and bug 866566 is created.

Comment 12

[Dylan Oliver [:doliver]]

Shelly, can you provide the current status on this bug?

Comment 13

[Shelly Lin [:shelly]]

Need review from Evelyn.

Comment 14

[Evelyn Hung]

Comment on attachment 742244 [details]
Patch

r=me, Sorry for my very late review.
This patch works but I think it's a workaround, it didn't resolve the real problem. Input focus should be removed when its window object is destroyed, it's not application's responsibility, which it means application have to aware and take care of keyboard app's status.
I'm fine to merge this patch as a temporary solution, but please file a bug as a follow-up for the real problem. Thank you so much.

Comment 15

[Evelyn Hung]

Hi Shelly, just saw your commit message:
"The forms.js did receive blur events when closing the child window, but somehow the Keyboard.jsm fail to receive any message."
So is it a keyboard API issue or process/thread communication issue? anyway, please help on filing a bug on it. Thank you.

Comment 16

[Evelyn Hung]

merged into Gaia master: 
https://github.com/mozilla-b2g/gaia/commit/a866e79190991a0d4678c3e7e47ffdcc5cfc744e

Gaia v1.0.1
https://github.com/mozilla-b2g/gaia/commit/12f401c87606160f6446f69c7c9541f52642331e

Gaia v1-train
https://github.com/mozilla-b2g/gaia/commit/00eb0194ebb3b4b776e8b46ec8a8c35931375029

Comment 17

[Deepa Subramanian]

Issue seems to be fixed. The numeric key board is not found while trying to pair a monoset bluetooth.

Inari Build ID: 20130506070205
Kernel Date: Feb 21
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/ce67220b877d
Gaia: 1e598d8842920d9e0b1743dc6fe9390bd5f6e2df

Leo Build ID: 20130506105248
Kernel Date: April 25th
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/00c554abfc17
Gaia: 94f03a82bc66ad04352d127747ca226368d96363

Comment 19

[Darren]

Created two test cases checking that the UI gets dismissed when pairing and canceling.

https://moztrap.mozilla.org/manage/cases/?filter-id=9442
https://moztrap.mozilla.org/manage/cases/?filter-id=9441