Tracking bug for removals after XPCOM extensions are no more?

[Henri Sivonen]

Do we have a tracking bug for all the stuff that we can and should
remove once we no longer support XPCOM extensions?

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Nathan Froyd]

We do not. Bug 1299187 is related to such work, but that bug only
covers unexporting symbols that 3rd party software would access. bz
has filed a few bugs for removing nsIDOM* methods that only existed
due to 3rd party compat concerns, but I don't think there's been
systematic evaluation of what's just dead weight now.
-Nathan

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Boris Zbarsky]

On 3/13/17 9:17 AM, Nathan Froyd wrote:
> We do not. Bug 1299187 is related to such work, but that bug only
> covers unexporting symbols that 3rd party software would access. bz
> has filed a few bugs for removing nsIDOM* methods that only existed
> due to 3rd party compat concerns, but I don't think there's been
> systematic evaluation of what's just dead weight now.

I suspect that pretty much all nsIDOM* stuff is effectively dead weight.
The only question is how much of it has internal consumers and how
hard it is to move those consumers to the webidl APIs instead.

There's a bunch of "good first bug" fodder here, easily parallelized, etc.

-Boris

[Steve Fink]

On 03/13/2017 06:17 AM, Nathan Froyd wrote:
> We do not. Bug 1299187 is related to such work, but that bug only
> covers unexporting symbols that 3rd party software would access. bz
> has filed a few bugs for removing nsIDOM* methods that only existed
> due to 3rd party compat concerns, but I don't think there's been
> systematic evaluation of what's just dead weight now.

For the record, there's some nonobvious stuff I can remove from the
rooting hazard analysis due to this -- currently, it conservatively
assumes that just about any nsISupports subclass's method could be
implemented in a binary extension, and thus could trigger a garbage
collection that moves all of your GC-controlled pointers while laughing
evilly at your now-bogus stack pointers to the old locations.

There's a whitelist of "safe" things that we assume will never be
overridden. But now I can remove everything that treats nsISupports
specially.

[Kris Maglione]

On Mon, Mar 13, 2017 at 08:36:05AM -0700, Steve Fink wrote:
>For the record, there's some nonobvious stuff I can remove from the
>rooting hazard analysis due to this -- currently, it conservatively
>assumes that just about any nsISupports subclass's method could be
>implemented in a binary extension, and thus could trigger a garbage
>collection that moves all of your GC-controlled pointers while
>laughing evilly at your now-bogus stack pointers to the old locations.

Are we talking about the removal of binary extension components, or
about removal of support for XUL/XPConnect extensions? Binary components
should already be gone. There are a lot of other things we should be
able to remove after we remove XUL extensions.

[Henri Sivonen]

On Mon, Mar 13, 2017 at 3:17 PM, Nathan Froyd <nfr...@mozilla.com> wrote:
> We do not.

OK. I filed one:
https://bugzilla.mozilla.org/show_bug.cgi?id=1347507

[Botond Ballo]

What will happen to WebExtension Experiments once these APIs start
being removed? My understanding is that WebExtension Experiments use
the same XPCOM APIs as XUL addons.

Cheers,
Botond

[Kris Maglione]

On Wed, Mar 15, 2017 at 03:26:19PM -0400, Botond Ballo wrote:
>What will happen to WebExtension Experiments once these APIs start
>being removed? My understanding is that WebExtension Experiments use
>the same XPCOM APIs as XUL addons.

The APIs that we're talking about removing have largely been
deprecated for a long time. The only reason they still exist is
the large number of legacy add-ons that still use them.

[Boris Zbarsky]

On 3/15/17 3:26 PM, Botond Ballo wrote:
> What will happen to WebExtension Experiments once these APIs start
> being removed? My understanding is that WebExtension Experiments use
> the same XPCOM APIs as XUL addons.

We shouldn't be removing APIs that have no alternative.

But I doubt a WebExtension experiment would use (as a concrete example)
nsIJSON instead of JSON.parse/stringify.

And we can work on removing non-scriptable XPCOM APIs of various sorts
(e.g. nsIDOM*), because obviously WebExtension Experiments (unlike
binary add-ons) can't use them.

-Boris

[Henri Sivonen]

On Wed, Mar 15, 2017 at 10:24 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> On 3/15/17 3:26 PM, Botond Ballo wrote:
>>
>> What will happen to WebExtension Experiments once these APIs start
>> being removed? My understanding is that WebExtension Experiments use
>> the same XPCOM APIs as XUL addons.
>
>
> We shouldn't be removing APIs that have no alternative.

In some cases there's an alternative, but the legacy dependencies are
turtles all the way down.

What's the current outlook on letting chrome JS read ArrayBuffers as
opposed to JS strings where the high 8 bits are zero and the low 8
bits are the byte values from XPCOM streams? (Or letting chrome JS
access things that are currently exposed as XPCOM streams via some
other thing that exposes bytes as ArrayBuffers?)

It would be good to remove nsIScriptableUConv, nsIConverterInputStream
and nsIConverterOutputStream sooner than later and let chrome JS use
TextDecoder like Web JS.

[Benjamin Smedberg]

On Wed, Mar 15, 2017 at 4:24 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 3/15/17 3:26 PM, Botond Ballo wrote:
>
>> What will happen to WebExtension Experiments once these APIs start
>> being removed? My understanding is that WebExtension Experiments use
>> the same XPCOM APIs as XUL addons.
>>
>
> We shouldn't be removing APIs that have no alternative.
>

As a blanket statement, I don't understand what this means.

I am thinking the exact opposite sentiment: after Firefox 57 when
Webextensions are the only extensions, if our product no longer needs some
functionality (and it's "API"), let's remove it. Quickly and ruthlessly. We
need to actively work to maintain less code.

Do we disagree, or do I misunderstand?

--BDS

[Boris Zbarsky]

On 3/15/17 6:51 PM, Benjamin Smedberg wrote:
> On Wed, Mar 15, 2017 at 4:24 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>> We shouldn't be removing APIs that have no alternative.
>
> As a blanket statement, I don't understand what this means.

As a blanket statement, it would depend on an implied "that have consumers".

> I am thinking the exact opposite sentiment: after Firefox 57 when
> Webextensions are the only extensions, if our product no longer needs some
> functionality (and it's "API"), let's remove it.

The key here is evaluating "needs".

> Do we disagree, or do I misunderstand?

I don't think we disagree.

-Boris

[Boris Zbarsky]

On 3/15/17 5:35 PM, Henri Sivonen wrote:
> What's the current outlook on letting chrome JS read ArrayBuffers as
> opposed to JS strings where the high 8 bits are zero and the low 8
> bits are the byte values from XPCOM streams?

I see no reason not to allow that. We'd just add this on
nsIScriptableInputStream, I assume, so we don't have to modify every
single stream impl....

There are some issues around doing this sort of thing on mainthread and
the resulting sync I/O in some cases, of course. But I don't think
they're any worse than with nsIConverterInputStream anyway.

-Boris

[Henri Sivonen]

On Thu, Mar 16, 2017 at 7:34 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> On 3/15/17 5:35 PM, Henri Sivonen wrote:
>>
>> What's the current outlook on letting chrome JS read ArrayBuffers as
>> opposed to JS strings where the high 8 bits are zero and the low 8
>> bits are the byte values from XPCOM streams?
>
>
> I see no reason not to allow that. We'd just add this on
> nsIScriptableInputStream, I assume, so we don't have to modify every single
> stream impl....

OK. Thanks. Turns out this is already on file:
https://bugzilla.mozilla.org/show_bug.cgi?id=923017

[Boris Zbarsky]

On 3/13/17 11:36 AM, Steve Fink wrote:
> There's a whitelist of "safe" things that we assume will never be
> overridden. But now I can remove everything that treats nsISupports
> specially.

Things can still be implemented in chrome JS via XPCWrappedJS, right?

Assuming the analysis will consider all known overrides of the relevant
virtual method, we need to also restrict to cases in which the relevant
class is builtinclass, I would think.

-Boris

[Kris Maglione]

On Wed, Mar 15, 2017 at 11:35:10PM +0200, Henri Sivonen wrote:
>What's the current outlook on letting chrome JS read ArrayBuffers as
>opposed to JS strings where the high 8 bits are zero and the low 8

>bits are the byte values from XPCOM streams? (Or letting chrome JS
>access things that are currently exposed as XPCOM streams via some
>other thing that exposes bytes as ArrayBuffers?)

This is already possible via nsIBinaryInputStream:

http://searchfox.org/mozilla-central/rev/571c1fd0ba0617f83175ccc06ed6f3eb0a1a8b92/xpcom/io/nsIBinaryInputStream.idl#71-82

[R Kent James]

On 3/15/2017 3:51 PM, Benjamin Smedberg wrote:
> after Firefox 57 when
> Webextensions are the only extensions, if our product no longer needs some
> functionality (and it's "API"), let's remove it. Quickly and ruthlessly. We
> need to actively work to maintain less code.

I'm struggling to have a big picture overview of what is going to be
removed. Let me state what I think the issue is, and see if I understand
correctly.

Certain APIs remain in the platform only because they were used by XUL
addons. Once XUL addons are disabled in Firefox, those will be removed.

The core XUL overlay feature however is used extensively throughout the
platform, and is not going to be removed as a result of disabling XUL
extensions (though it might be removed in the future as a part of
eliminating XUL from the platform). Examples are the overlay features in
XULDocument.cpp

Is that reasonable correct?

:rkent

[Bobby Holley]

This sounds about right. In practice, I think the goal is that a green run
on treeherder should be the primary criterion of what is landable, rather
than a bunch of downstream consumers whose breakage is only discovered when
we release.


>
> :rkent

[Henri Sivonen]

The stated purpose of nsIBinaryInputStream is very different from the
stated purpose of nsIScriptableInputStream. Since the needed code is
already in the former, should we nonetheless tell people to use the
former and deprecate the latter instead of trying to modernize the
latter within its stated purpose?

(I'd be fine with changing the documentation on both IDLs to broaden
the stated purpose of nsIBinaryInputStream and to deprecate and
hopefully subsequently remove nsIScriptableInputStream. Fewer nsIFoo
is better.)

[Kris Maglione]

I think that deprecating nsIScriptableInputStream in favor of
nsIBinaryInputStream makes sense. nsIScriptableInputStream can only be
used to read binary data, in any case. Having it operate on JS strings
only confuses things.

[Ehsan Akhgari]

On 2017-03-16 2:29 PM, Bobby Holley wrote:
> On Thu, Mar 16, 2017 at 11:23 AM, R Kent James <ke...@caspia.com> wrote:
>

> This sounds about right. In practice, I think the goal is that a green run
> on treeherder should be the primary criterion of what is landable, rather
> than a bunch of downstream consumers whose breakage is only discovered when
> we release.

Also, there are a whole bunch of architecture changes that we would like
to make which we have been unable to due to the existence of XPCOM based
add-ons.

For example in Gecko we cannot parse URLs on any threads other than the
main thread right now, and this has been seriously making it a pain to
implement Web features. The reason we can't fix it is because the APIs
we'd need to break are used by add-ons (bug 922464). After Firefox 57,
we should remove the ability to write a Web Extension experiments that
allows you to hook into Gecko's URL parsing infrastructure in the
current way in JS. If there are consumers of any APIs that get in the
way of architectural changes like this (that is, code on
mozilla-central, or comm-central, such code should be rewritten.) Of
course in case the code affected is on comm-central we will be doing our
best to inform folks and file bugs in advance as much as we can.

Cheers,
Ehsan

[Frank-Rainer Grahl]

Firefox will probably loose enough usera already because of the webextensions
only policy so you might rather add something to the api instead of taking
things away. If its a useful api someone will use it when writing extensions.

FRG