1063228 - Accessing the rocketbar before the homescreen is loaded makes the close button don't work

Status: VERIFIED FIXED

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

Description

[Alberto Pastor [:albertopq]]

Build Information
Device: Flame
Gaia      a47ecb6368c015dd72148acde26413fd90ba3136
Gecko     757931d0149e
BuildID   20140904000203
Version   34.0

Description

When entering in the rocketbar, clicking on the Search input, before the homescreen is fully loaded (the icons are not shown) avoids the close button to work properly.

Steps to Reproduce
1. Restart the phone
2. AS soon as you see the Search input, tap over it
3. When the search screen is shown, click on the 'Close' button

Expected Results

It goes back to the homescreen

Actual Results

The close button doesn't work

Other Notes

Clicking again on the input (the keyboard is displayed) makes the close button work again.

Reproduction Frequency: 90%

Comment 1

[Kevin Grandon :kgrandon]

[Blocking Requested - why for this release]: This is a pretty bad experience since you can get locked inside of this search window.

Comment 2

[Kevin Grandon :kgrandon]

Attachment: Github pull request

There are a few issues here. The main issue reported here is not being able to exit because the search app gets into a weird state. This is a problem of us relying on keyboard events and it seems that the keyboard is not ready in time.

I think this does expose another issue of the search app closing on startup though, but this is much less severe. I think we should land this first part, then solve the other part in another bug.

Comment 3

[Kevin Grandon :kgrandon]

Comment on attachment 8484675 [details] [review]
Github pull request

Ben or Alberto - would one of you mind giving this simple setTimeout() guard a review?

Comment 4

[Kevin Grandon :kgrandon]

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

Comment 5

[Kevin Grandon :kgrandon]

Comment on attachment 8484675 [details] [review]
Github pull request

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Search implementation, likely present since 2.0.
[User impact] if declined: It's rare, but users may get stuck in the search app if they trigger it too quickly after startup. It's a bad experience.
[Testing completed]: Manual testing.
[Risk to taking this patch] (and alternatives if risky): Low risk, simple patch.
[String changes made]: None.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

v2.1: https://github.com/mozilla-b2g/gaia/commit/be32405e87774632eaccbc211e4aa71c57de6c09

Comment 7

[pete siphantong [:Petes]]

This bug is verified fixed on the Flame 2.1 (319mb) and the Flame 2.2 (319mb)


Flame 2.2 Master KK (319mb) (Full Flash)

Device: Flame 2.2 Master
BuildID: 20141011040204
Gaia: 95f580a1522ffd0f09302372b78200dab9b6f322
Gecko: 3f6a51950eb5
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Flame 2.1 KK (319mb) (Full Flash)

Device: Flame 2.1
BuildID: 20141011000201
Gaia: f5d4ff60ffed8961f7d0380ada9d0facfdfd56b1
Gecko: d813d79d3eae
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Result: close button worked, It goes back to the homescreen

Comment 8

[Kevin Grandon :kgrandon]

Issue does not reproduce on desktop, and there's no easy way to test system startup right now. testsuite- for now until we have a way to granularly test startup. We will triage for automation in the future.