Closed Bug 938288 Opened 6 years ago Closed 5 years ago

[User Story] Ability to Open System Browser

Categories

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

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: pdol, Unassigned)

References

Details

(Whiteboard: [ucid:System109, 1.3:P2, ft:systems-fe], system-browser [p=3] )

Attachments

(1 obsolete file)

User Story:
As a user, I can open the System Browser via an icon so that I can start browsing in a familiar way.

Acceptance Criteria:
1. Clicking on the System Browser icon launches the System Browser.

Assumptions: 
1. Display of the System Browser icon will not be in shipping version of product until full System Browser is implemented.
Flags: in-moztrap?(nhirata.bugzilla)
My current thinking on how to implement this is that we create a homescreen bookmark with the following properties:

{
  title: 'System Browser',
  url: 'about:newtab',
  icon: (base64 encoded generic browser icon),
  features: 'toolbar=yes,location=yes'
}

which in 1.3 is only added in engineering builds along with all the apps listed in apps-engineering.list

The "features" string can be used as an argument when calling window.open and is already a web standard (https://developer.mozilla.org/en-US/docs/Web/API/Window.open). We can use this as a mechanism to tell the window manager what browser chrome to display.

"location" refers to the location bar, i.e. the Rocketbar.

"toolbar" refers to the bottom bar.

In 1.3 "location" can be set to "no" by default, then in 1.4 we can make it default to "yes" to turn on the Rocketbar everywhere. That means in 1.3 we can craft this special bookmark which opens a window to display the "system browser" chrome which would otherwise not be displayed.

This requires that we have the ability to:
* Define default homescreen bookmarks at build time (which is also a requirement of the bookmarks migration work, bug 940647)
* Store "features" of a homescreen bookmark to pass as arguments to window.open when it is launched
* Have the window manager display different parts of browser chrome based on the arguments passed to window.open

'about:newtab' refers to a special about: page which can be the new tab page of Firefox OS (equivalent to the new tab page in desktop Firefox), as per the final Browser OS UX spec. We would implement this in content rather than chrome in the same way that we create the start page in the current browser app.
Depends on: 940647
Assignee: nobody → bfrancis
Component: Gaia::System → Gaia::System::Window Mgmt
Alive, I don't think this bug lives in the Window Mgmt component. The "Have the window manager display different parts of browser chrome based on the arguments passed to window.open" part is the window manager (maybe we should file a different bug for that). I think this bug should track the work to add the special browser bookmark to engineering builds.
(In reply to Ben Francis [:benfrancis] from comment #2)
> Alive, I don't think this bug lives in the Window Mgmt component. The "Have
> the window manager display different parts of browser chrome based on the
> arguments passed to window.open" part is the window manager (maybe we should
> file a different bug for that). I think this bug should track the work to
> add the special browser bookmark to engineering builds.

Gotcha!
Component: Gaia::System::Window Mgmt → Gaia::System
Depends on: 940989
No longer blocks: 1.3-systems-fe
Obviously this doesnt produce a working browser, but getting started, will file new bugs for the follow up work needed, few things I would want to fix before landing though

Vivien, I dont want base64 images embedded in our build scripts, a first step fix would be to create a gaia/distribution_default/homescreens.json, we would use this as the GAIA_DISTRIBUTION_DIR by default, we should also have a better way to reference assets, I could possible do a app://homescreen.gaiamobile/images/browser2.png thing, then we could have this work properly across resolutions (also really want to avoid using base64)

Christian, you ok with this method for bootstrapping bookmarks? it goes through pretty much the same code path as the initial mozApps
Attachment #8337753 - Flags: feedback?(cristian3100)
Attachment #8337753 - Flags: feedback?(bfrancis)
Attachment #8337753 - Flags: feedback?(21)
Worth noting, these bookmarks differ from the work that has to be done in https://bugzilla.mozilla.org/show_bug.cgi?id=940647, those bookmarks need to take account of carrier variants, may want to rename this one to system_bookmarks
https://bugzilla.mozilla.org/show_bug.cgi?id=942852 is another bug filed to show the url bar when the option is passed into the wrapper
Comment on attachment 8337753 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/14019

Didnt realise app resources could be referenced directly, the way we do configuration can be improved, but this works for now.
Attachment #8337753 - Flags: review?(21)
Attachment #8337753 - Flags: feedback?(cristian3100)
Attachment #8337753 - Flags: feedback?(bfrancis)
Attachment #8337753 - Flags: feedback?(21)
This is great :)

This puts the icon on the first homescreen page with collections which is fine for this dogfooding feature, but for the full default homescreen bookmarks feature needed as part of bookmarks migration I'm guessing we'll need to specify where the bookmarks go.

Other default bookmarks will need to vary depending on the MCC+MNC codes from the SIM card, but even "system bookmarks" will need to be localised so we may want to think about how we'd do that.

Is that the Aurora logo? :P
Assignee: bfrancis → dale
Yeh I expect a bunch of changes required to the way we configure bookmarks and several parts of this, I was going to add the position customisation thing but even that is going to require a bunch of other changes so suggest getting this merged as it makes life easier to start working on the several other things in parallel (carrier variant bookmarks, bookmark migration, wrapper supporting rocketbar etc)
and yup, Aurora logo, nightly was already used
Fixed lint errors and addresed review comments, waiting on green travis run before pushing
Component: Gaia::System → Gaia::System::Browser
No longer blocks: browser-chrome-mvp
https://moztrap.mozilla.org/manage/case/1687/ still applies.
Flags: in-moztrap?(nhirata.bugzilla) → in-moztrap+
Whiteboard: [ucid:System109, 1.3:P2, ft:systems-fe], system-browser → [ucid:System109, 1.3:P2, ft:systems-fe], system-browser [p=3]
Reopening to track continued work on this.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #8337753 - Attachment is obsolete: true
Depends on: 1053251
Depends on: 1053256
Depends on: 1053258
Depends on: 1053261
No longer depends on: 940647
Depends on: 1054447
Blocks: rocketbar-mvp
No longer blocks: browser-chrome-mvp
No longer depends on: 1054447
No longer depends on: 1053261
No longer depends on: 1053251
Depends on: 1055688
Depends on: 1054489
Deassigning myself from meta bug
Assignee: dale → nobody
No longer depends on: 1055688
There may be some follow-ups to do, but we have a working trigger so I think we can close this out.
Status: REOPENED → RESOLVED
Closed: 6 years ago5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.