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
> 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
>
> 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
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
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'
>>>
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.
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
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
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
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
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
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
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
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
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
15 matches
Mail list logo