Hi Tim,
Generally speaking, I completely agree with you that our "chrome
events" design is shitty.
I think it's great if we can replace the events with "real" APIs like
mozApps.mgmt.onlaunchrequest.
However I also want to be mindful of that it might be non-trivial to
implement these things in Gecko. And given that we will have exactly
one consumer, the system app, I don't want to spend too much time on
implementing the perfect API.
But absolutely, in places where it's easy to add methods on the
appropriate API, I definitely think we should do exactly that. For
example I would imagine that we already have APIs on the browser API
which is exposed only to the system app. So adding more features to
the browser API which is only exposed to the system app shouldn't be
much work I would imagine?
Regarding permissions, we could simply add a "system-app" permission
which is only given to the system app. That way we could pretty easily
add WebIDL annotations which takes care of security checks. No need to
invent specific permissions for specific APIs.
This matches what we do for the "system principal" in Gecko, where we
different pages have different principals, but where all Gecko
internals just run with a single shared "system principal" which is
given a whole host of capabilities.
To capture the APIs where for whatever reason it wouldn't be easy to
build a "real" API, we could do something like
callback SystemAppMessageHandler = void (any messageBody);
interface SystemAppMessages {
addMessageHandler((sequence<DOMString> or DOMString) messageType,
SystemAppMessageHandler handler);
sendMessage(DOMString messageType, any messageBody);
}
So the system app could register different handlers for different
message types. And on the Gecko side we can have a generic way to send
and receive simple strings and structured clones.
How does that sound? I'd definitely like to hear Fabrice's thoughts too.
/ Jonas
On Thu, Jul 23, 2015 at 12:32 AM, Tim Guan-tin Chien
<[email protected]> wrote:
> 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
