1111524 - [Flame][Homescreen]Hide the keyboard in the e.me search view, the recommended apps are overlap with the apps in Homescreen.

Status: RESOLVED FIXED

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

Description

[Lancy(Leave from Mozilla)]

Attachment: screenshot.png

[1.Description]:
[Flame][v2.1][Homescreen]Tap the search bar on Homescreen and search the keywords, hide the keyboard, the recommended apps overlaps with the apps on Homescreen.
Attach screenshot:screenshot.png.
Attach logcat:logcat.txt.
Occurrence time:13:15

[2.Testing Steps]: 
1.Tap the search bar in Homescreen.
2.Search the keywords.
3.Long press the space key to hide the keyboard.

[3.Expected Result]: 
3.The recommended apps and the apps in Homescreen should be shown at different levels.

[4.Actual Result]: 
3.The recommended apps overlaps with the apps on Homescreen.

[5.Reproduction build]: 
Gaia-Rev        97873dca486abf4162a3345e71b375806937bdec
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ec87f4f41d3d
Build-ID        20141214001202
Version         34.0

[6.Reproduction Frequency]: 
Twice,2/30
TCID: Free Test

Comment 1

[Lancy(Leave from Mozilla)]

Attachment: logcat.txt

Comment 2

[Kevin Grandon :kgrandon]

It says that 2.2 is unaffected here. Can we perform a reverse regression window to see which commit fixed this in 2.2?

Comment 3

[Lancy(Leave from Mozilla)]

Attachment: logcat.txt

Hi Kevin,

This issue can be reproduced on Flame v2.1&v2.2, and the Flame v2.2 should be marked as affected. I have found the real reason and the steps need to be updated.
See the attachments: Verify1_1111524.mp4 & logcat.txt.
Reproducing rate: 2/30
Occurrence time:16:57

1.Tap the search bar in Homescreen.
2.Search the keywords.
3.MT call and reject the call.
4.Tap the search bar and search the keywords again.
5.Long press the space key to hide the keyboard.

Expected Result: 
The recommended apps and the apps in Homescreen should be shown at different levels.

Actual Result:
The recommended apps overlaps with the apps on Homescreen.

Flame 2.1 version:
Gaia-Rev        14315733e2d265a42f9ab02d1aba191789870f70
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ddecea83ce6e
Build-ID        20141218001205
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141218.034928
FW-Date         Thu Dec 18 03:49:39 EST 2014
Bootloader      L1TC00011880

Flame 2.2 version:
Gaia-Rev        58734e8a48157f99d5b733412b600c2e04c954fe
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/5c7a6294b82a
Build-ID        20141218040201
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141218.074532
FW-Date         Thu Dec 18 07:45:43 EST 2014
Bootloader      L1TC00011880

Comment 4

[Lancy(Leave from Mozilla)]

Attachment: Verify1_1111524.mp4

Comment 5

[Kevin Grandon :kgrandon]

Removing keyword since 2.2 is affected as well.

Comment 6

[Kevin Grandon :kgrandon]

Moving into window management. Seems to happen pretty regularly when receiving a call, so perhaps  attention window and search window are not playing well together.

Comment 7

[(inactive after 6/18) Alive Kuo [:alive]]

I think this is a rocketbar bug, root cause might be here https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/rocketbar.js#L165

The finish() is setup in step 3 in comment 3 but it is not executed until keyboard hide itself in step 5 in comment 3.

Not sure how to fix but I think options are:
* Rocketbar does not need to deactivate itself on attention window opening.
* Rocketbar should clear the event listener on activated.
* Rocketbar should not rely on keyboard to block its deactivate progress.

Kevin, what do you think? Could you take this or find someone to take it?

Comment 8

[Kevin Grandon :kgrandon]

It seems like this was added in bug 1053318 in order to show the app transition, I guess if we don't do this then we don't have a transition? It also seems that we have a setTimeout() guard here which calls finish, even if we don't get the event, so it seems weird that it could be caused by that.

It does seem that we're missing a guard for the backdrop event listener, which could be causing it. In any case, I'll take the bug and do some investigation.

Comment 9

[GitHub Autolander Bot]

Attachment: [PullReq] KevinGrandon:bug_1111524_rocketbar_safety to mozilla-b2g:master

Comment 10

[Kevin Grandon :kgrandon]

Comment on attachment 8551061 [details] [review]
[PullReq] KevinGrandon:bug_1111524_rocketbar_safety to mozilla-b2g:master

Etienne - could you help me review this? I've added a simple utility to back an event with a timeout as it's a fairly common thing we're doing in gaia. I've also ported a few places that perform this logic to the new utility. Let me know what you think, thanks!

Comment 11

[Etienne Segonzac (:etienne)]

Comment on attachment 8551061 [details] [review]
[PullReq] KevinGrandon:bug_1111524_rocketbar_safety to mozilla-b2g:master

First, the code change: a-ok, just adding symmetry since we already had a safetyTimeout for the activation phase.

Then, the helper: I agree with Chris that we shouldn't hide gaia css or platform issues with safety timeouts. And this helper makes it easier :/
That said, it makes the code so much more readable and it actually makes those kind of timeouts grepable so we can remove them more easily later on (as the helper comment suggests).

So thumbs up!

Comment 12

[Kevin Grandon :kgrandon]

Thanks for the review. I agree that we shouldn't have these safety timeouts, but I also think that we can't get rid of them until we have web animations. I'll address your comments and get this landed.

Comment 13

[Kevin Grandon :kgrandon]

In master: https://github.com/mozilla-b2g/gaia/commit/b8bbdd4cd38023b68221a1338ce1f6fff2817dfc

Comment 14

[Kevin Grandon :kgrandon]

Comment on attachment 8551061 [details] [review]
[PullReq] KevinGrandon:bug_1111524_rocketbar_safety to mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Rocketbar feature implementation I believe.
[User impact] if declined: Occasionally poor experience when using rocketbar.
[Testing completed]: Manual testing, and a unit test added as well.
[Risk to taking this patch] (and alternatives if risky): Only adds an additional guard. Since no new functionality was added assuming low risk.
[String changes made]: None.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/36e457378dd3f8fc92f4590eb95fcb81984cadcc

Comment 16

[Sue]

Attachment: verify_video.MP4

This issue has been verified successfully on Flame 2.2/3.0
See attachment:verify_video.MP4
Rate:0/30

Flame 2.2 build:
Gaia-Rev        80d5b797fd0497a7e3337b7798a21b2e1219681a
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/01bf1516a65b
Build-ID        20150127002504
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150127.035842
FW-Date         Tue Jan 27 03:58:52 EST 2015
Bootloader      L1TC000118D0

Flame 3.0 build:
Gaia-Rev        b02ec9713e6de8d96c6954d2c0dfd0442b0656ac
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/38e4719e71af
Build-ID        20150127010228
Version         38.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150127.043726
FW-Date         Tue Jan 27 04:37:39 EST 2015
Bootloader      L1TC000118D0