Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-17 Thread Valentin Gosu
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 wrote: > > Code

Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-16 Thread Jonathan Kingston
> 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

Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-15 Thread Andrea Marchesini
> > My understanding is that the change in question here was not backed > out due to the extension being broken, and that should continue to be > the case. I'd love to be corrected here if I have this wrong! > You are right. Removing nsIJSON interface I broke ContextualIdentityService.jsm and

Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-15 Thread Tanvi Vyas
We can easily make the containers addon a Web Extension and take out the bootstrap.js code. But until today (with 57 out the door), we couldn't do that. We could only host one version of the addon on AMO, so we had to host one that was compatible with release. Now that 57 is out the door, we

Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-15 Thread Robert Helmer
On Wed, Nov 15, 2017 at 8:31 AM, Kris Maglione 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' >>>

Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-15 Thread Andrew McKay
To confirm, yes we have a list of all the add-ons that are bootstrapped. To get access to that special ability the teams agree that testing and maintenance is their responsibility. I agree that removing legacy XPCOM functionality is the priority and the focus should be keeping tree herder green.

Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-15 Thread Kris Maglione
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

Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-15 Thread Andrew Swan
On Wed, Nov 15, 2017 at 6:12 AM, Henri Sivonen wrote: > How many Mozilla-signed special extensions are there? Does an analog > of https://dxr.mozilla.org/addons/ exist for searching their code? Unfortunately there is not an index of them. andym could provide a complete

Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-15 Thread Boris Zbarsky
On 11/15/17 10:00 AM, Henri Sivonen wrote: the notion of there still existing out-of-tree XPCOM callers but them being dark matter code search-wise worries me. Yes, I agree. We should make sure any such callers are indexed by some dxr or searchfox instance. And I don't mean an instance per

Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-15 Thread Henri Sivonen
On Wed, Nov 15, 2017 at 4:31 PM, Boris Zbarsky wrote: > On 11/15/17 9:12 AM, Henri Sivonen wrote: >> >> How many Mozilla-signed special extensions are there? Does an analog >> of https://dxr.mozilla.org/addons/ exist for searching their code? > That wouldn't have helped in this

Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-15 Thread Boris Zbarsky
On 11/15/17 9:12 AM, Henri Sivonen wrote: How many Mozilla-signed special extensions are there? Does an analog of https://dxr.mozilla.org/addons/ exist for searching their code? That wouldn't have helped in this case. The addon was not using nsIJSON. The addon was messing up a non-addon

Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-15 Thread Henri Sivonen
On Wed, Nov 15, 2017 at 3:16 PM, Andrea Marchesini wrote: > Containers is not a 'normal' addon. It's an hybrid addon signed with the > mozilla key and in its install.rdf it has hasEmbeddedWebExtension tag set to > true. > This means that it has and it executes

Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-15 Thread Andrea Marchesini
Containers is not a 'normal' addon. It's an hybrid addon signed with the mozilla key and in its install.rdf it has hasEmbeddedWebExtension tag set to true. This means that it has and it executes bootstrap.js with chrome privileges. bootstrap.js is needed for FF versions <56: a couple of

Re: Still-supported cases of out-of-tree XPCOM code?

2017-11-15 Thread Peter Van der Beken via dev-platform
It might be because this is a legacy 'embedded WebExtension' addon signed by Mozilla. It doesn't get disabled in 57 because it's signed by Mozilla. But we really should just load the WebExtension instead of using the legacy addon code imho. On 15/11/2017 10:04, Henri Sivonen wrote: > I don't

Still-supported cases of out-of-tree XPCOM code?

2017-11-15 Thread Henri Sivonen
I was surprised to see that the removal of nsIJSON (https://bugzilla.mozilla.org/show_bug.cgi?id=1347515) broke the multi-account-containers add-on. I don't quite understand the breakage. It seems to relate not to nsIJSON itself but to how extension-side XPCOM JS imports WebIDL interfaces