On Sun, Aug 2, 2015 at 9:45 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Fri, Jul 31, 2015 at 6:04 PM, Fabrice Desré <fabr...@mozilla.com> 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.
>
I hope we don't couple different APIs too much. Creating an API that
has no purpose on it's own other than bridging calls from other APIs,
sound like collecting mozChromeEvents in a nicer way and not actually
get rid of it in concept.
Especially when we have already know these events will not be handled
by one single component in System UIs.
I would opt for an embedded API only if we have strong need to finish
off this on the short term, e.g. if we want to move System app our of
the root process soon. That API would still be an FIXME though :'(
>>> 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?
>
The plain bloody fact is, not single event from shell.js to System app
is covered in any tests other than end-to-end tests like Gij or Gip.
You simply can't test shell.js in Firefox Desktop mochitests because
they are not packaged in these builds.
I assume by mocking, Fabrice means mocking |shell.sendChromeEvent| to
ensure it is being called from the API code. My questions for this
approach would be (1) is that the test we want and we could to live
with and (2) if it's doing able why isn't it's already being done.
Forgive me for not understand Gecko JSM imports enough to tell if it's
actually doable without seeing one example.
Other than Fx Desktop, we don't have Chrome mochitests in B2G so we
couldn't import shell.js directly and test it.
We are indeed testing APIs in B2G mochitests. However, I want to call
out bug 1094055, which makes mochitest frames impossible to get be run
in-proc when running on B2G, let alone being hosted by shell.html
directly and catch these events.
These are conclusions I have on our current test infra, gathered while
working on mozInputMethod API. Correct me if I am wrong and please
please tell me some good news.
>>> 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.
>
We already have mozApps.mgmt. What's conceptually different between
management methods and embedder, system-only methods?
(I already spoken about standalone embedding API above)
>>> 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
That's what I have been doing and I plan to continue to do so, if
there are management support.
_______________________________________________
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
