Currently we have a separate everything.me bar on the homescreen. When the Rocketbar is enabled it should be displayed in the expanded state on the homescreen and should replace the everything.me search bar, as per the UX spec.

Work in progress patch to have Rocketbar expanded on the homescreen.

In which bug is the homescreen work being tracked? I don't think we should land it without having a commit that's reviewed for the homescreen at the same time.

Comment on attachment 8401554 [details] https://github.com/mozilla-b2g/gaia/pull/17959 Generally looks good, but I am concerned about putting an R+ on this without seeing homescreen changes or knowing what the plan is.

Thanks Kevin, I will make the tweaks to the integration test in the morning. I'm not sure we can afford to hold this up for the homescreen work as there's lots more left to do for next week which builds on this patch. It surely isn't doing much harm behind a build-time pref?

There are folks who are dogfooding with rocketbar turned on and it would be a shame to break their homepage. The first page isn't so bad, but covering icons on other pages is not so good I think. Do we have a bug for the homescreen work filed somewhere?

(In reply to Kevin Grandon :kgrandon from comment #5) > There are folks who are dogfooding with rocketbar turned on and it would be > a shame to break their homepage. The first page isn't so bad, but covering > icons on other pages is not so good I think. Do we have a bug for the > homescreen work filed somewhere? I have the same question: the patch seems to display rocketbar always when homescreen is opened. As Kevin said, this will causing sizing issues with 2nd page, 3rd page...of homescreen. Currently I don't have a good suggestion for 'how to display rocketbar only in landing page of homescreen', could you tell me your plan to go? Even this is not harmful because it's pref off, I still wanna to know what's the proposed architecture to prevent we will be fixing more bugs in the future. What's in my mind: (1) IAC between homescreen and system to show/hide rocketbar on demand. (2) Homescreen should notice rocketbar is enabled to hide ev.me search bar. or (3) Homescreen should implement its own rocketbar...

(In reply to Ben Francis [:benfrancis] from comment #0) > Currently we have a separate everything.me bar on the homescreen. > > When the Rocketbar is enabled it should be displayed in the expanded state > on the homescreen and should replace the everything.me search bar, as per > the UX spec. Could you put the UX link here? Thanks.

Comment on attachment 8401554 [details] https://github.com/mozilla-b2g/gaia/pull/17959 Let's have more communication before rush landing.

(In reply to Alive Kuo [:alive][NEEDINFO!][God bless Taiwan.] from comment #6) > I have the same question: the patch seems to display rocketbar always when > homescreen is opened. That is correct. Please see page 21 of the latest UX spec here https://mozilla.app.box.com/s/8b59zir45jm1vp7xtsxy The Rocketbar is supposed to be expanded on all pages of the homescreen. This is version 0.13 of the spec, but this has been the design since version 0.8 in February! The latest visual designs I have seen show a semi-transparent Rocketbar on the homescreen with the wallpaper showing through, which would require the Rocketbar overlaying the homescreen and the homescreen app having padding at the top. https://mozilla.app.box.com/s/z96qna0oli4azccgwx3u We were asked to keep a black Rocketbar for user testing, which is what I have done. As of our meeting on Tuesday the design for the homescreen in 2.0 was still in flux, but seems likely it will be vertically scrolling and will not have horizontal paging. The homescreen 2.0 work is tracked by the vertical homescreen meta bug https://bugzilla.mozilla.org/showdependencytree.cgi?id=989848&hide_resolved=1 and all the requirements for user testing are tracked by this meta bug https://bugzilla.mozilla.org/showdependencytree.cgi?id=993116&hide_resolved=1 As you can see, there is a great deal of work left to do on the Rocketbar by the 17th April for user testing, so I would be grateful if we could not delay reviewing this bug for another 24 hours. If any dogfooders complain about having half of app icons obscured until the homescreen work is completed for the 17th then please point them in my direction and I will explain the requirements around user testing. I would not recommend that people start dogfooding with Rocketbar turned on at build time at this stage.

Comment on attachment 8401554 [details] https://github.com/mozilla-b2g/gaia/pull/17959 r+ if we are not overloading screen element's classes. Anyway it doesn't make sense to record homescreen's state "by rocketbar". If we really need this it should be updated by HomescreenLauncher or HomescreenWindow. And it's better next time there's a spec and some following together with the review request to avoid confusion. Thanks!

Please be sure to file a follow-up bug to fix the current homescreen. Homescreen2 is initially landing as an optional homescreen, and users will have the choice to upgrade. I am fairly sure that we either need to support both, or whitelist origins.

Comment on attachment 8401554 [details] https://github.com/mozilla-b2g/gaia/pull/17959 OK, I addressed all the review comments and I figured out a way to track the "home" state without setting classes on the "screen" element as Alive originally asked for. Kevin, would you be able to give this one last check over before I land?

Comment on attachment 8401554 [details] https://github.com/mozilla-b2g/gaia/pull/17959 I didn't see a bug filed for the homescreen work, and it's important that it doesn't get lost so I've filed bug 995021 to track this. Thanks!

Thanks Kevin, I didn't realise you meant a bug for the *current* homescreen. I fixed an integration test and merged into master in https://github.com/mozilla-b2g/gaia/commit/0488a4a75e670a8b756771323b55d4ad404ebb4d