According to page 5 of the Browser Chrome UX interaction spec the Rocketbar should collapse into the statusbar as you scroll down on the homescreen. Currently it slides underneath. https://mozilla.app.box.com/s/lbw2wzw3p4jvxs24k4sg/1/2099951272/19877711201/1

Francis, did we reach a conclusion on whether this requires a re-design of the edit state of the homescreen, and do we have a spec for that?

Hi Ben, If I remember correctly, you mentioned that it wouldn't be possible to hide the Rocket bar completely in edit mode. However, would it be possible to keep the rocket bar, but have it collapse when the edit mode is launched?

I'm sure we will also see this problem in the general web. I've noticed that browsing any kind of site with a sticky header will also cause problems. Just wanted to make a note that we probably shouldn't special-case anything for the homescreen here - we should come up with something that will solve it for the web.

(In reply to Francis Djabri [:djabber] from comment #2) > If I remember correctly, you mentioned that it wouldn't be possible to hide > the Rocket bar completely in edit mode. However, would it be possible to > keep the rocket bar, but have it collapse when the edit mode is launched? The only way I can think of to obscure the Rocketbar is to use a popup window for the edit mode. The downside of that is that you'd lose your scroll position when you switch to edit mode and you have to create a whole new window. There isn't really any web standard way for an app to tell the Rocketbar to collapse (that's why people have historically used scroll position hacks to try to hide URL bars on mobile browsers). The alternative is to revert back to older designs of the edit mode where the search bar is still displayed during edit. That way there would be no problem with scroll position and the user could manually collapse/expand the Rocketbar by scrolling.

The only way we can realistically go back to the older design of the edit mode and get rid of the Edit header would be to re-introduce the wiggling icons, but as I understand it, there were some performance limitations. Kevin, Chris, do you know if this is fixable? If we can't get this fixed, we will need to leave the search field as it is on the home screen and have it scroll off view, which would be a shame as it's a great learning opportunity for users.

(In reply to Francis Djabri [:djabber] from comment #5) > The only way we can realistically go back to the older design of the edit > mode and get rid of the Edit header would be to re-introduce the wiggling > icons, but as I understand it, there were some performance limitations. > Kevin, Chris, do you know if this is fixable? We can look at this, but I don't think we can guarantee to have this in 2.1. I think we need a solution here that works for web content as well.

(In reply to Kevin Grandon :kgrandon from comment #3) > I'm sure we will also see this problem in the general web. I've noticed that > browsing any kind of site with a sticky header will also cause problems. > Just wanted to make a note that we probably shouldn't special-case anything > for the homescreen here - we should come up with something that will solve > it for the web. Are you talking about the fact that scrolling on the homescreen happens in an inner frame, so scrolling can't be used to collapse the Rocketbar? I think that's really a separate problem and in the general web case I think the only foolproof solution is bug 1043928 (provide a manual mechanism to expand/collapse the Rocketbar). The problem I'm talking about here is that even if we can get the homescreen scrolling happening in the top level frame, the UX design doesn't allow us to separate the Rocketbar out from the homescreen. This is just because of the requirement that in the edit mode the "Edit" header covers up the Rocketbar. Either we need to find a way to make this part of the homescreen app obscure the Rocketbar (I can't think of a way to do that well), or we need a new UX design in which the Rocketbar can still be visible in edit mode, but can be collapsed by scrolling.

(In reply to Ben Francis [:benfrancis] from comment #7) > Either we need to find a way to make this part of the homescreen app obscure > the Rocketbar (I can't think of a way to do that well), or we need a new UX > design in which the Rocketbar can still be visible in edit mode, but can be > collapsed by scrolling. Why wouldn't a website need to also have this functionality? If we need it, I'm sure they will also? (In reply to Francis Djabri [:djabber] from comment #5) > If we can't get this fixed, we will need to leave the search field as it is > on the home screen and have it scroll off view, which would be a shame as > it's a great learning opportunity for users. Ok, let's plan on having it this way for FL. We will see what we can do here and if we can fix it we will and ask for uplift.

(In reply to Kevin Grandon :kgrandon from comment #8) > (In reply to Ben Francis [:benfrancis] from comment #7) > > Either we need to find a way to make this part of the homescreen app obscure > > the Rocketbar (I can't think of a way to do that well), or we need a new UX > > design in which the Rocketbar can still be visible in edit mode, but can be > > collapsed by scrolling. > > Why wouldn't a website need to also have this functionality? If we need it, > I'm sure they will also? So what do you have in mind? Currently the only web standard way for an app to obscure the Rocketbar is to go fullscreen, or use a popup dialog (bug 1054556). I think the homescreen UX design is unique in that it assumes that the Rocketbar is part of the homescreen so it can obscure it. I don't see why ordinary web content would assume that the URL bar is part of their app. The only other approach I can think of is to add a new API to the DOM in Gecko to allow an app to tell the URL bar to hide itself. Do you think that's something that could be standardised? I really feel the solution here is a new UX design which doesn't assume the Rocketbar is part of the homescreen. It would be a real shame for the main screen of the OS not to have the Rocketbar transition. I would actually argue that it would be better to not scroll the Rocketbar off the screen at all on the homescreen than have an inconsistent transition, but that's obviously a call for UX.

We might be able to change the title and statusbar color to make rocketbar look like the edit mode header? I think it'd be worth a prototype to see what it looks like, but maybe that's just crazy.

(In reply to Kevin Grandon :kgrandon from comment #8) > Ok, let's plan on having it this way for FL. We will see what we can do here > and if we can fix it we will and ask for uplift. I'm really uncomfortable about punting this to the next release. Having the Rocketbar collapse properly on the homescreen feels like a core part of Rocketbar UI and vital for demonstrating that Rocketbar is a system-wide feature and teaching users how it works. Are the dependent bugs about scrolling the main frame of the homescreen app not realistically fixable for 2.1, or is it just the UX design issue discussed in this bug that's the problem? Are we really OK with shipping like this?

(In reply to Ben Francis [:benfrancis] from comment #11) > Are the dependent bugs about scrolling the main frame of the homescreen app > not realistically fixable for 2.1, or is it just the UX design issue > discussed in this bug that's the problem? > > Are we really OK with shipping like this? If it is between not shipping at all vs. shipping w/ the current implementation, we'll ship. Yes, we lose out on the discoverability of Rocketbar if you're scrolled down on the homescreen (which is a core part of the interaction model). I can't comment on fixing the dependent bugs. I just know this is at risk given we only have a few days left.

(In reply to Ben Francis [:benfrancis] from comment #11) > Are the dependent bugs about scrolling the main frame of the homescreen app > not realistically fixable for 2.1, or is it just the UX design issue > discussed in this bug that's the problem? Yes, Gfx bugs are part of the problem and currently preventing us from moving forward. Bug 1056423 for example needs to be fixed, it's possible that bug 1043859 would fix it though.

(In reply to Kevin Grandon :kgrandon from comment #13) > (In reply to Ben Francis [:benfrancis] from comment #11) > > Are the dependent bugs about scrolling the main frame of the homescreen app > > not realistically fixable for 2.1, or is it just the UX design issue > > discussed in this bug that's the problem? > > Yes, Gfx bugs are part of the problem and currently preventing us from > moving forward. Bug 1056423 for example needs to be fixed, it's possible > that bug 1043859 would fix it though. Animating the icons in edit mode is not reasonably doable in the 2.1 timeframe, to be honest. Could we not just hide the rocketbar in edit mode?

Here's a thought, not sure if it's a good one or not, but what if we request fullscreen during home screen edit mode? I need to see how the dialogs and permission levels work and such, but maybe if we request fullscreen the rocketbar will just hide itself?

Kevin, can you maybe play around with it enough to give us an estimate for effort so we can decide if it's worth spending time to fix this?

Yup, I am planning on spending some time on this over the next few weeks.

Here is a work-in-progress patch which seems to work fairly well. Still need to figure out edit mode, but I've started playing with using full-screen when entering/exiting edit mode and it seems to work fairly well.

Comment on attachment 8523511 [details] [PullReq] KevinGrandon:bug_1053747_homescreen_rocketbar_collapse to mozilla-b2g:master Chris - could you take a look at this when you get a chance? This patch makes it so we use the system expand/collapse for rocketbar. The reason we couldn't do this before was due to not having a good solution for edit mode. I'm currently trying to enter full-screen during edit mode, which should solve that for us. There are still a few bugs to be solved with fullscreen edit mode, but I think this might be a decent start and I'd like to get your opinion if we should continue down this path.

Comment on attachment 8523511 [details] [PullReq] KevinGrandon:bug_1053747_homescreen_rocketbar_collapse to mozilla-b2g:master The fullscreen solution unfortunately is not ideal due to a number of reasons. I think I'd like to investigate using the <meta> tag approach to control the rocketbar from the home screen.

Based on the information I got, the target milestone for this bug could be 2.2 Sprint 4. Please feel free to change it if I am wrong. Thank you very much.

The UX spec seems not define rocketbar behavior for edit mode.

The rocket bar should not appear or be actionable in edit mode

> The rocket bar should not appear or be actionable in edit mode This is very tricky to implement because web content (in this case the homescreen content) can't usually obscure the URL bar. The only way I can think to implement this is to have the edit mode as a separate window without a URL bar which overlays the homescreen, but that's architecturally very different from what we have now and would require a lot of re-factoring. What happens if the Rocketbar is already collapsed when entering edit mode? Should it disappear from the status bar? Kevin, you suggested using a meta tag in the search app to control when the Rocketbar is shown. Did you make any progress with this? I'm a bit concerned from a security point of view about supporting a meta tag which allows web content to hide the URL bar. Paul, do you have thoughts on that? I still think the best solution would be a new UX design for edit mode which doesn't obscure the Rocketbar.

Yes, I have a patch in bug 1110239 which adds a <meta> tag to control the URL bar. It doesn't hide it, but collapses it instead, so I don't really think there is security concerns there. People also commented in the bug that they wanted it to only be for home screens, so I think we can do that for now - though I don't think it's necessary. The <meta> tag works quite well for controlling the rocketbar when entering/exiting edit mode. The bigger problem I was running into was actually the home screen dialogs were the wrong size with the <meta> tag. I need to do more investigation here, and I'm not sure I'll have time in 2.2 to do it. If we can think of some UX where we don't need to manually control the rocketbar, that would be a much better first step. Perhaps we could change the title of the home screen during edit mode, and remove the current header?

(In reply to Kevin Grandon :kgrandon [INACTIVE - heads down on Gij Issue] from comment #27) > Yes, I have a patch in bug 1110239 which adds a <meta> tag to control the > URL bar. It doesn't hide it, but collapses it instead, so I don't really > think there is security concerns there. Sounds fine to me, but also sounds like you are hoping for a different design so you don't need to use a meta tag.

Confirmed today that this will not make the 2.2 timeline. Feature was a nice-to-have item, not must-have.

Taking this. I think we might need to redesign the homescreen for this, but I'm also working on a new homescreen prototype and I don't plan on rewriting in-app search logic :)

Comment on attachment 8606371 [details] [gaia] Cwiiis:bug1053747-searchbar-on-homescreen > mozilla-b2g:master This is just the system part of Kevin's patch + a small fix for utility tray colouring and a rebase. This reinstates the collapsible rocketbar on all homescreens.

Comment on attachment 8535658 [details] [PullReq] KevinGrandon:bug_1053747_homescreen_rocketbar_collapse_2 to mozilla-b2g:master Thank you for picking this up!

Comment on attachment 8606389 [details] [gaia] Cwiiis:bug1053747-searchbar-on-homescreen-not-collapsible > mozilla-b2g:master This adds a non-collapsible scrollbar to homescreens (which better suits my design). WIP.

Repo for the prototype homescreen I'm working on: https://gitlab.com/Cwiiis/homescreen-ng

Comment on attachment 8606389 [details] [gaia] Cwiiis:bug1053747-searchbar-on-homescreen-not-collapsible > mozilla-b2g:master This branch is obsolete - Fixed issues in other branch, you can have a non-collapsible rocketbar on a homescreen by just not having a scrollable document body.

Comment on attachment 8606371 [details] [gaia] Cwiiis:bug1053747-searchbar-on-homescreen > mozilla-b2g:master This adds a rocketbar to all homescreens, but also adds a blacklist so that we don't break the current verticalhome.

Comment on attachment 8606371 [details] [gaia] Cwiiis:bug1053747-searchbar-on-homescreen > mozilla-b2g:master It's not trivial so I'd like to see some tests. Also, I read the code about adding 'home-app' but not sure what's your desire: Are you using this class to identify a homescreen window but it's not our vertical home? Or are you using this class to identify all homescreen window? If yes let's use .homescreen or .homescreenWindow instead of creating a new class. If you need to identify the 3rd party homescreen let's call it '3rdparty-home' or something else to make more semantic. Lemme know if you have problem. Thanks.

Comment on attachment 8606371 [details] [gaia] Cwiiis:bug1053747-searchbar-on-homescreen > mozilla-b2g:master I removed the extra style-class, fixed my not-quite-right fixing of a statusbar colour issue and added a couple of unit tests. I haven't observed any incorrect behaviour and all the tests pass, but I'd not be hugely surprised if this causes some wrongness somewhere - I think, barring other issues, we should land it and use bug reports to figure out these possibly untested scenarios (as I can't think of any to pre-empt and write tests for).

Comment on attachment 8606371 [details] [gaia] Cwiiis:bug1053747-searchbar-on-homescreen > mozilla-b2g:master Cool, makes much sense to me than the last patch. Thank you.

Master: https://github.com/mozilla-b2g/gaia/commit/eaba95985744eeb9a1f59d9e2f80b77d42389917

\o/ finally. Thank you Chris!

(In reply to Ben Francis [:benfrancis] from comment #43) > \o/ finally. Thank you Chris! Just to note, this unfortunately doesn't apply to vertical home :)

Hi Chris, I tried below master build, but the rocketbar cannot collapse to statusbar at Homescreen when dragging down. I am not so sure if this is correct? Could you clarify? *Test env Build ID 20150614160203 Gaia Revision 1bf2da102560481748ff3f6202fbed5c4daa5832 Gaia Date 2015-06-13 00:22:05 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/3c26bef95d54 Gecko Version 41.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150614.195926 Firmware Date Sun Jun 14 19:59:37 EDT 2015 Bootloader L1TC000118D0

(In reply to Hermes Cheng[:hermescheng] from comment #45) > Hi Chris, > > I tried below master build, but the rocketbar cannot collapse to statusbar > at Homescreen when dragging down. I am not so sure if this is correct? Could > you clarify? > > *Test env > Build ID 20150614160203 > Gaia Revision 1bf2da102560481748ff3f6202fbed5c4daa5832 > Gaia Date 2015-06-13 00:22:05 > Gecko Revision > https://hg.mozilla.org/mozilla-central/rev/3c26bef95d54 > Gecko Version 41.0a1 > Device Name flame > Firmware(Release) 4.4.2 > Firmware(Incremental) eng.cltbld.20150614.195926 > Firmware Date Sun Jun 14 19:59:37 EDT 2015 > Bootloader L1TC000118D0 This only applies to alternative home-screens, the vertical home screen retains its previous behaviour. Eventually, the vertical homescreen will either be replaced (most likely) or updated.