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.

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.

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!

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

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] 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.

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

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

Green build: https://travis-ci.org/mozilla-b2g/gaia/builds/14606199 https://github.com/mozilla-b2g/gaia/commit/0d57ec2801ae125ec855a19cf956ab118660d694

https://moztrap.mozilla.org/manage/case/1687/ still applies.

Reopening to track continued work on this.

Deassigning myself from meta bug

There may be some follow-ups to do, but we have a working trigger so I think we can close this out.