This is a general idea on our Device API evolution. I want to bring
this up and make sure it's a workable idea.
TLDR: Let's move mozChromeEvent to it's respective origin APIs and
expose them under |navigator.mozFoo.mgmt| with a special
|foo-manage-system| permission that we will only grant to System app.
1) What are mozChromeEvents
mozChromeEvent and mozContentEvent are ad-hoc event name we give for
custom events dispatches between shell.js (w/ chrome privilege) and
System app (an packaged app with permissions listed in it's manifest).
We use this because some of the Gecko APIs rely on System app to
actually act on it on the UI layer. For example,
* mozApps and mozSystemMessage rely on System app (specifically,
window management) to actually create and show the app frame to launch
an app.
* mozInputMethod rely on System app input mgmt to respond to focus
event and show the keyboard
* WebNotification API rely on System app to actually show the
notifications, and respond to user interaction on the notifications.
2) How they are implemented
If you look at shell.js you would see basically everyone dump a few
line of observers, and convert Gecko-internal observer message into
the event. There are other alternatives like import "SystemAppProxy"
into your jsm and call the event sending method.
3) It works, how bad is it
3.1) mozChromeEvent poses a performance problem, since a lot of
components in System app need to listen to it, we ended up having 30x
event listeners installed and only one of these callbacks will
actually act on it.
3.2) Spaghetti in shell.js is in no way testable other than Gaia
integration tests, but in fact they are part of APIs that should have
been testable in dom/*/mochitests/
3.3) By allowing 3.1 and 3.2 to continue live in the tree we are not
delivering the best experience we could. We also deny the mission of
B2G on figuring out what is needed to construct an OS with Web
technologies.
3.4) It only works in-process. I don't know if that's desirable but if
it's possible to run System app in non-root process, we should
definitely do it.
4) Proposed evolution direction
I proposed for applicable mozChromeEvent or mozContentEvents use
cases, we should move them back to their respective APIs, and only
expose these method/events with a special |-system| permission. For
example, the open-app event is dispatched whenever Gecko need Gaia
System to create an app frame, it could be replaced with an interface
like this (DOMApplicationsManager is exposed under
|navigator.mozApps.mgmt|)
partial interface DOMApplicationsManager : EventTarget {
[CheckAnyPermissions="webapps-manage-system"]
attribute EventHandler onlaunchrequest
}
And Gaia System window management will act on this event.
5) Possible alternatives
There will always be some System level UIs and we will always need
some place to host it. The only alternative I could think of would be
granting chrome privilege to System app, but even with that we will be
only fixing 3.1 and not 3.2-4.
6) What's not applicable
The one big exception here is the Browser API proxies. Sometimes
System app would need to access the Browser API methods exposed to
it's own embedder. Unless we implement some kind of
|navigator.mozControlMyOwnBrowserFrame| API to host these methods, we
would be still rely on shell.js to use them, for now. I can send out
another proposal if people are interested.
==
Specifically call out to :pault, :sicking, :fabrice, and :vivien for
response on this, as you are the owners of security and B2G
runtime-related matter. If there is no strong objection I will begin
to work on this.
Thanks!
Tim
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
