On Fri, Jul 31, 2015 at 6:04 PM, Fabrice Desré <[email protected]> wrote:
> Hi all,
>
> Sorry for the late reply...
>
> Let's do a bit or b2g archeology... and go back to this discussion:
> https://groups.google.com/forum/#!topic/mozilla.dev.webapi/2ykFnFyOJSc
>
> I don't think much has changed in terms of proposal. As you can see, we
> didn't come to a consensus, hence the FIXME that I put more than 3 years
> ago in
> http://hg.mozilla.org/mozilla-central/annotate/afa67b6957bb/b2g/chrome/content/shell.js#l751
>
> I would be very happy if you could get rid of that!
If a decision is needed, I'd say we should do the "flat" proposal
since that seems to require less boilerplate code in the
implementation. I.e. a mozEmbed object with all the necessary
But really, I'm happy to let whoever writes the patch implement
whatever approach they want.
>> 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/
>
> I'm not sure about the testability issue. We can write mocks for all the
> uses we have I believe, but we still have debt here.
I *really* like the idea of being able to write mochitests which
ensure that calling various DOM APIs fire the expected callbacks in
the system app.
But is this really harder when we're using DOM events?
>> 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.
>
> I'm not a fan of adding an embedding part to "normal" web apis. I'd
> rather have the embedding api stand on its own.
I kind'a agree. If nothing else it's easier to document when the two
are cleanly separated.
But I don't feel strongly.
>> 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.
>
> Granting chrome privileges to the system app is not an option. It's a
> sure road to evil things.
Yeah. One big problem with granting the system app chrome privileges
is that it makes it much more fragile to allow addons to inject into
the system app.
I'd also be worried about partners modifying the system app using chrome code.
> Overall, that will be quite some work to fully remove these events. We
> have to be careful with the return on investment here. As much as I'd
> like that to happen, I also have several other projects that need
> similar skills for people that have cycles left!
Definitely agree. But if the people working on the system app feel
like it makes it possible for them to reduce technical debt, then I
definitely think that they should submit patches to gecko. This part
of gecko is all JS I think, so shouldn't be too different from
modifying Gaia.
/ Jonas
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
