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%

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

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 on attachment 8484675 [details] Github pull request Ben or Alberto - would one of you mind giving this simple setTimeout() guard a review?

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

Comment on attachment 8484675 [details] 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.

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

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

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.