On 08/02/2015 08:01 AM, Tim Guan-tin Chien wrote: > 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.
I don't see anything wrong with with concept of having an embedding api. But we can agree that we disagree on that ;) > Especially when we have already know these events will not be handled > by one single component in System UIs. But even with a single mozEmbedding api, nothing would prevent different components of the system app to provide their feature, right? Eg, mozEmbedding.onlaunchapp = ... in some apps module and mozEmbedding.onchoseactivity = ... in the activity module. > 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. Yes, Gi tests are the equivalent of mochitest-chrome in firefox desktop, where you need the full UI to run the tests. > 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. We usually test web apis using plain mochitests that don't involve product specific UI. That means that we bypass the UI hooks during tests at the api level (for instance we don't wait for the installation confirmation dialog in mozApps tests). I agree that we currently have a gray zone in b2g where the b2g glue in shell.js/SystemAppProxy.jsm is only exercised by Gi tests. But since this is where the coupling between gecko and gaia happens, this seemed acceptable to me to catch regressions. I also agree that it would be even better to have more tests than what we currently have in https://mxr.mozilla.org/mozilla-central/source/b2g/components/test/mochitest/ > 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. No good news, sorry. Looks like we still need to fix this bug :( > 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) The difference to me is that mozApps.mgmt methods can be used legitimately by more apps than the embedding api. More generally, there is also the case of features that don't have an existing content facing api to hook on, like system messages or activities (they just have a public constructor). Fabrice -- Fabrice Desré b2g team Mozilla Corporation _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
