Re: Please use nsGlobalWindow{Inner,Outer}

Bug 1416384 (https://bugzilla.mozilla.org/show_bug.cgi?id=1416384) has landed on central now, and it completely removes nsGlobalWindow in favour of the new nsGlobalWindow{Inner,Outer} classes. There is still plenty of code cleanup to do, but the type split itself is now complete. If you need help

mozilla-central now compiles with C++14

C++14 constructs are now usable in mozilla-central and related trees. According to: https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code this opens up the following features for use: * binary literals (0b001) * return type deduction * generic lambdas * initialized lambda captures

Re: FF57 Web Extension Content Script ReferenceError

Sounds a lot like it! I'll follow that bug and contribute my findings. On Wednesday, 15 November 2017 22:42:51 UTC+1, Kris Maglione wrote: > This is probably bug 1408996. > > On Wed, Nov 15, 2017 at 01:34:44PM -0800, Jip de Beer wrote: > >This simple web extension used to work on FF51 and still

Re: FF57 Web Extension Content Script ReferenceError

This is probably bug 1408996. On Wed, Nov 15, 2017 at 01:34:44PM -0800, Jip de Beer wrote: This simple web extension used to work on FF51 and still works on Google Chrome. But it no longer works reliably on FF57 when loading the content script for https://vk.com/. I get the following error:

FF57 Web Extension Content Script ReferenceError

This simple web extension used to work on FF51 and still works on Google Chrome. But it no longer works reliably on FF57 when loading the content script for https://vk.com/. I get the following error: ReferenceError: Awesomplete is not defined contentscript.js:464:5 The extension adds an

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

> > 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?

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?

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' >>>

Late Intent to unship: several internal CSS properties with Stylo

There are several CSS properties, which are supposed to be internal, unintentionally unshipped from web content with Stylo. We didn't notice that until we started looking at internal properties support in chrome. The properties already unshipped in Firefox 57 are: -moz-window-opacity

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

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?

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?

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?

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?

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?

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: Intent to require Python 3 to build Firefox 59 and later

It would make my heart sing if all python 3 code we write would have defined types (using mypy in in ./mach lint). It would definitely remove the feeling of "walking blindfolded" when doing any change with the python tooling. At least I hope providing types would be allowed if not required. --

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

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?

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?

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

Re: Intent to unship: mozmm CSS unit.

On 11/15/2017 11:51 AM, Jonathan Kew wrote: > On 15/11/2017 03:32, Emilio Cobos Álvarez wrote: > >> So, I've looked through and I haven't found any related minutes (I've >> looked for minutes that mentioned "physical", of which they were many, >> but all related to physical properties and scroll

experimentalObjectRestSpread now turned on for ESLint

We've just landed a patch in mozilla-central that turns on support in ESLint for Object Rest/Spread properties. Javascript support for these landed in FF 55 (bug 1339395 ), and ESLint should now let you use them. More details on the

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

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