The W3C "Manifest for Web application" specification proposes a "display" property in the manifest which allows a web developer to choose a display mode for their app. In order to support this specification in Firefox OS we would need to add functionality into the window manager. I suggest the following mappings: fullscreen - app window in full screen mode, limited to app scope standalone - app window with no app chrome, limited to app scope minimal-ui - app window with app chrome, limited to app scope browser - browser window (with browser chrome), not limited to any scope I think that if the "browser" display mode is specified we should just add a homescreen bookmark which opens in the browser, for all other display modes we should install an app. This is handled in bug 1003876. This bug is to track adding support for the "fullscreen", "standalone" and "minimal-ui" display modes for installed apps.

Alive, do you have any advice regarding how to implement this? I'm no longer sure about the comment "I think that if the 'browser' display mode is specified we should just add a homescreen bookmark" so ignore that for now. Where in the window manager code should we apply a display mode to a window?

Do you want to deprecate manifest.fullscreen? * If yes, modify AppWindow#reConfig, AppWindow#isFullScreen, AppWindow#isFullScreenLayout * If no, what will happen if fullscreen=true&display=standalone or fullscreen=false&display=fullscreen? isFullScreenLayout is manifest.fullscreen_layout which ignore software home button, I am not sure how it related to display mode. Anyway there is no 'one-line-fix' way to switch current chrome/fullscreen decision to support display, but it would not be too difficult.

Comment on attachment 8563542 [details] [gaia] benfrancis:1088009 > mozilla-b2g:master I think if the W3C manifest "display" property is present and has a valid value then it should get precedence, otherwise we should fall back to the mozApps "chrome" and "fullscreen" properties for backwards compatibility. Does this patch look like it's going in the right direction? Note: This pull request also contains a commit from bug 1003876 which hasn't landed yet, I'm just asking for feedback on the second commit https://github.com/benfrancis/gaia/commit/9bfd146c55d123fbb24c4f33b6189c8131b33307

Comment on attachment 8563542 [details] [gaia] benfrancis:1088009 > mozilla-b2g:master I only read the appWindow change and it looks like a sane cleanup! Thanks Ben.

Comment on attachment 8566534 [details] [gaia] benfrancis:1088009-2 > mozilla-b2g:master Added unit tests and integration tests, ready for review

Comment on attachment 8566534 [details] [gaia] benfrancis:1088009-2 > mozilla-b2g:master Kevin, it seems Alive may be away celebrating the Chinese New Year! Any chance you could review this? Already has f+ from Alive.

Comment on attachment 8566534 [details] [gaia] benfrancis:1088009-2 > mozilla-b2g:master Not too happy with how crazy the attribute switching is getting, but this looks good to me. Feel free to land with my review since we're trying to get this in quickly. Thanks!

Comment on attachment 8566534 [details] [gaia] benfrancis:1088009-2 > mozilla-b2g:master Thanks Kevin. It is pretty crazy, but I hope we can eventually start to deprecate our proprietary properties in favour of the W3C ones.

https://github.com/mozilla-b2g/gaia/pull/28310 Autolander could not land the pull request due to not having collaborator rights. This is possibly due to a tree closure. Please check the tree status and request checkin again once the tree is open.

Oops, tree is closed, but should be open soon I think. (In reply to Ben Francis [:benfrancis] from comment #11) > It is pretty crazy, but I hope we can eventually start to deprecate our > proprietary properties in favour of the W3C ones. Is there anything stopping us from deprecating our proprietary ones in 3.0? I'd like to file a bug to do so and try to get those removed in 3.0 if possible.

I wondered that too. We could phase out support for old properties in newer versions of Firefox OS but what I'm not sure about is what we do about backwards compatibility for old versions of Firefox OS which don't get any OTA updates. We could have apps in the Marketplace which only work in >=3.0 or only work in <=2.2 depending on which version of the manifest they use. I don't know whether we have a strategy for that yet.

The other option is that we treat the mozApps apps and W3C web apps completely separately. W3C web apps are not meant to be used through a installation API, that's just what I'm using internally to register the apps in the app registry. We could promote using a W3C manifest via a link relation in web pages, separately from the mozApps manifests which get submitted to the Firefox Marketplace for use with an install button. We could support W3C manifests in the Marketplace, but only provide an "open" button rather than an "install" button so that users always navigate to the app first, before installing it via browser chrome. That would allow us to separate the code paths a little more, which may or may not be a bad thing. Currently this implementation of the "display" property is not entirely to the W3C spec because the "browser" default of the W3C spec conflicts with the "standalone" default of mozApps. I guess a lot of this depends on what direction we take in 3.0.

Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/08e0eeefb17c4c764ca934d8fb79ea0d66be6052