Trying to land bug 1407679, which merges nsIIOService2 into nsIIOService, triggered some crashes on Android. It seems the hostutils is also affected by XPCOM changes. Bug 1415242 updated it and fixed the crashes.
On 15 November 2017 at 17:35, Jonathan Kingston <j...@mozilla.com> wrote: > > Code search wouldn't have helped *this* case, but considering how > useful https://dxr.mozilla.org/addons/ has been previously, the notion > of there still existing out-of-tree XPCOM callers but them being dark > matter code search-wise worries me. > > This was failing for quite some time, we kept ahead of the failures when > firefox was radically changing this. > > I agree a test suite would help for these addons for stability going > forward as maintaining this for containers was a hard task. > > I would like to re-iterate what Baku said, there was a log failure that > wasn't picked up and was thought to be the failure. It however wasn't and > the actual bug was in central impacting Nightly container users also. > > > If the file is needed for <56, why does it even run in 57 or 58? > > The code shouldn't run for those versions, there was an import for all > versions which caused an error however didn't even prevent the rest of the > file from loading which is used to make the embedded extension load. > > On Wed, Nov 15, 2017 at 4:31 PM, Kris Maglione <kmagli...@mozilla.com> > wrote: > > > On Wed, Nov 15, 2017 at 04:12:06PM +0200, Henri Sivonen wrote: > > > >> On Wed, Nov 15, 2017 at 3:16 PM, Andrea Marchesini > >> > >>> This is why we had this issue. It should not be impossible for a > >>> 'standard' > >>> webextension to generate such mess. > >>> > >> > >> How many Mozilla-signed special extensions are there? Does an analog > >> of https://dxr.mozilla.org/addons/ exist for searching their code? Is > >> there a CI system testing that the continue to work? > >> > > > > The situation is pretty bad at this point. Ideally, all XPCOM add-ons > that > > we support should run tests in treeherder on checkin, both for add-on > > changes and m-c changes. But as of now, most system add-ons, Test Pilot > > add-ons, and SHIELD studies are hosted on Github and do their own ad-hoc > > testing, mostly using Node-ish testing frameworks. > > > > There's also no standard place to host or index all of this add-on code, > > or even to get a list of what such add-ons exist. At one point, I asked > for > > all SHIELD add-ons to at least be hosted in the same Github organization. > > The same should probably go for all other Mozilla-signed add-ons. That > > would at least give us a single place to find any XPCOM add-on code that > we > > still support. > > > > In the mean time, though, as far as I'm concerned, the maintainers of > > those add-ons are responsible for dealing with breakage that results from > > not having in-tree tests and a standard place to search that code. If > > you're removing legacy XPCOM functionality, all you should need to care > > about is whether treeherder is green. > > > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
