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! Some more comments inline. On 07/23/2015 12:32 AM, Tim Guan-tin Chien wrote: > 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. We are using not just "mozChromeEvent" but different "mozChromeXXX" event names to not pay this performance penalty. > 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. > 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. That would help, yes, though we could inject our event passing mechanism as a frame script in the system app too and remote the 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. > 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. 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! Fabrice -- Fabrice Desré b2g team Mozilla Corporation _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
