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

RESOLVED FIXED in 2.2 S4 (23jan)

Status

defect
--
major
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: yulan.zhu, Assigned: kgrandon)

Tracking

unspecified
2.2 S4 (23jan)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.1 affected, b2g-v2.2 verified, b2g-master verified)

Details

(Whiteboard: [systemsfe])

Attachments

(6 attachments)

(Reporter)

Description

4 years ago
Posted image 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
(Reporter)

Comment 1

4 years ago
Posted file logcat.txt
blocking-b2g: --- → 2.2+
Whiteboard: [systemsfe]
(Assignee)

Comment 2

4 years ago
It says that 2.2 is unaffected here. Can we perform a reverse regression window to see which commit fixed this in 2.2?
(Reporter)

Comment 3

4 years ago
Posted file 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
Flags: needinfo?(kgrandon)
(Reporter)

Comment 4

4 years ago
Posted video Verify1_1111524.mp4
(Assignee)

Comment 5

4 years ago
Removing keyword since 2.2 is affected as well.
(Assignee)

Comment 6

4 years ago
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.
Component: Gaia::Homescreen → Gaia::System::Window Mgmt
Flags: needinfo?(kgrandon)
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?
Flags: needinfo?(kgrandon)
(Assignee)

Comment 8

4 years ago
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.
Assignee: nobody → kgrandon
Blocks: 1053318
Status: NEW → ASSIGNED
Flags: needinfo?(kgrandon)
Target Milestone: --- → 2.2 S3 (9jan)
(Assignee)

Comment 10

4 years ago
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!
Attachment #8551061 - Flags: review?(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!
Attachment #8551061 - Flags: review?(etienne) → review+
(Assignee)

Comment 12

4 years ago
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.
(Assignee)

Comment 13

4 years ago
In master: https://github.com/mozilla-b2g/gaia/commit/b8bbdd4cd38023b68221a1338ce1f6fff2817dfc
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Assignee)

Comment 14

4 years ago
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.
Attachment #8551061 - Flags: approval-gaia-v2.2?(bbajaj)
Keywords: verifyme
Attachment #8551061 - Flags: approval-gaia-v2.2?(bbajaj) → approval-gaia-v2.2+

Comment 16

4 years ago
Posted video 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

Updated

4 years ago
Keywords: verifyme

Updated

4 years ago
QA Whiteboard: [MGSEI-Triage+]
You need to log in before you can comment on or make changes to this bug.