Closed Bug 1069975 Opened 10 years ago Closed 7 years ago

Have Rocketbar collapsed by default for all types of window


(Firefox OS Graveyard :: Gaia::System::Browser Chrome, defect, P1)




tracking-b2g backlog


(Reporter: daleharvey, Unassigned)


(Whiteboard: [systemsfe])

Somewhat of a regression, the old frames were basically fullscreen, but now if you bookmark say, its impossible to get rid of the chrome
I know we have gone back and forward on the spec for this a few times so wondering what the plan to address this would be

First reaction was we can give the user the option when making the bookmark, but thats fairly nasty, ideally I think we have a nice way to interact with an expanded rocketbar (with back button etc) on apps and treat bookmarks as apps (eventually trying to treat everything the same way)
Flags: needinfo?(fdjabri)
When you say "full screen" I assume you mean "non-scrollable" as in they're 100% height?

I think the only reliable solution to this may be UI to manually collapse the Rocketbar, see bug 1043928.
Yup scrollable

I think manually collapsing / expanding the rocketbar will be required, but its not going to be the full solution since I dont want to manually hide it every time. 

I am kinda hoping when we implement that we can just keep the rocketbar minimised all the time unless the user opens it, its not needed like 99% of the time, but either way lets fix that then figure this out
blocking-b2g: --- → backlog
Priority: -- → P1
Whiteboard: [systemsfe]
I've updated the title of this bug to more accurately summarise the problem I think you're describing.

Firstly, you're talking about bookmarks which open in a browser window rather than "apps" which have a special meaning in Firefox OS as something installed into the app registry and open in an app window.

Secondly, when you say "full screen" I think you mean a web page which can't be scrolled because it is set to 100% height. Full screen again has a special meaning in Firefox OS to mean something that also covers the status bar.

So, assuming that I've understood you correctly, I think this is mainly a duplicate of bug 1043928. The user needs a way to collapse the Rocketbar in the case when a web page can't be scrolled.

To the broader point of treating apps and bookmarks the same, I originally thought this too but through prototyping Web Manifest I've come to the conclusion that apps and bookmarks are separate but complimentary things which shouldn't be treated entirely the same.

An app is a collection of web pages within a defined URL scope used separately from the browser. A bookmark should be a shortcut to a single page at a particular URL inside a web site *or* web app.

Web Manifest has a "display" property which allows the developer to specify a display mode for their app. The options are fullscreen, standalone, minimal-ui and browser. I have a proposal in bug 1088009 about how to map these display modes to Firefox OS.

I agree with you that giving the user the option to set their own display mode when bookmarking a page is probably a bad idea. Firstly, the content may not actually work well in a display mode it wasn't designed for and secondly a bookmark is just a single URL, there's no way to tell what URL scope the display mode should apply to. In either of these cases it's too easy for the user to end up at a dead end on a web page with no back button and the only way to recover is to close the browser window and start again.

Whether or not the Rocketbar should be expanded or collapsed on browser windows by default is really up to UX, but personally I like the current approach of it being expanded by default, then collapsing on scroll. We just need a way to collapse it when scrolling won't work.

I think ultimately what you'd like to be able to do as a power user is to create an installed "app" from any web page, even if it doesn't provide a manifest to define a display mode and a URL scope to which that display mode should apply. Dietrich has a Firefox extension called "standalone" which does this. That would be cool, but I think is actually quite tricky because it requires defining a display mode and URL scope yourself, and it would be a footgun for a lot of users who could end up with something un-useable.

I propose we make this a duplicate of bug 1043928 unless there are any remaining issues to address?
Summary: Cant hide chrome on full screen web apps → Can't collapse Rocketbar in browser windows with a non-scrollable web page
Non scrollable web pages was only one obvious use case, having the rocketbar scroll up and down as I scroll any bookmark is somewhat of a regression compared to the previous implementation.

I think ideally we have the rocketbar permanently collapsed until the user decides they want to use it for navigation.

This isnt a dupe of 1043928 which is fairly specific
I suppose you can call it a regression, but really it's an intentional change of design.

1) We now open EverythingMe results and homescreen bookmarks in browser windows rather than a special type of app window with app chrome.
2) For browser windows and app windows which request navigation chrome, we have a navigation bar expanded by default, which in some cases can't be collapsed.

I think 1 is a good thing. I agree that 2 sucks for use cases like bookmarking Google Maps to the homescreen.

I'm not sure that always having Rocketbar collapsed by default is a great answer though. If you can expand it, you need a way to collapse it again, so we'd definitely need bug 1043928.

Leaving for UX input on how to provide better UI for this use case.
Summary: Can't collapse Rocketbar in browser windows with a non-scrollable web page → Have Rocketbar collapsed by default for all types of window
Clearing, gonna fix this elsewhere
Flags: needinfo?(fdjabri)
FWIW I don't think this is something that needs "fixing", it is implemented to the UX specification and behaves as expected.

Feel free to propose a different design though.

Actually I've proposed a different design in this presentation (see page 6 and page 9).

My proposal was that Rocketbar should be expanded by default when browsing, but "pinning" an app or page should pin the Rocketbar in the collapsed position. For an app this applies to the scope of the app (defined in the manifest), for a page it applies only to the URL of the page.

Here's a motion design for it that Eric created
blocking-b2g: backlog → ---
No longer blocks: dale-being-happy
Thank for providing useful knowledge about UX, I have applied my website and now It becomes a solid website, just thank you again
Flags: needinfo?(bfrancis)
Flags: needinfo?(bfrancis)
Firefox OS is not being worked on
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.