Why gaia apps are turned to chrome://?

I am curious to know why apps are turned into chrome:// I came to know that chrome is a visible part of an application. Is there any advantage of turning apps into chrome:// ? Please explain.


This is only for applications that requires specific privileges: system, settings, keyboard, homescreen, search. Serving them as chrome content simplifies this. Maybe @fabrice can give you more informations if you need :slight_smile:


Thanks for asking :slight_smile:

As part of the B2G Transition Project we’re deprecating Mozilla’s proprietary mozApps system (also known as “Open Web Apps”) in favour of new standard web apps using the W3C Manifest and Service Workers (also known as “Progressive Web Apps”). We’re also deprecating several APIs which are tied closely to legacy mozApps, and removing the mozApps permissions model.

It’s important that we remove legacy technologies from Gecko when web standard solutions become available, but in this case standard web apps can not do everything that Mozilla’s proprietary apps could do. Gaia was built as a collection of mozApps which can carry out all sorts of privileged tasks like changing device settings, making phone calls and sending text messages.

The mozApps permissions model allows privileged apps which have been reviewed and signed by Mozilla to carry out those privileged operations, but once we remove that permissions model that will no longer be the case. This is why we’re moving to a new architecture which is more like the Firefox web browser which has only privileged browser “chrome” and web content.

In this new model the core system apps like system, lockscreen, homescreen, search, keyboard and settings will become “chrome” so that they can continue to carry out those privileged operations, and everything else will become standard web apps.

Making these system apps into chrome also simplifies a lot of the code in Gaia because all of the system pieces share the same “origin”. That means we can replace proprietary DataStore usage with standard IndexedDB and replace proprietary Inter-App communication with standard postMessage via a BroadcastChannel for example.

This new simpler model is more compliant with new web standards and more aligned with the architecture of Firefox so we hope it will be easier to maintain going forwards.

Hope this helps.



Thanks for answering @lissyx @benfrancis :slight_smile: Also, I linked this question on Transition Wiki page so that people like me have better idea & avoids duplicate questions arising on this topic :slight_smile:


Hi Ben,

The move towards progressive web apps sounds great.

I was wondering about dialer/messaging support. These are essential features for a smartphone that seem unlikely to be made available through web apps. Are there plans by Mozilla to move these to chrome as well?

1 Like

Yes, you can see more details here : https://public.etherpad-mozilla.org/p/b2g-transition-requirements


they are being done :slight_smile: