Re: Tracking bug for removals after XPCOM extensions are no more?

[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

Benjamin Smedberg wrote:

On Wed, Mar 15, 2017 at 4:24 PM, Boris Zbarsky  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



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[Ehsan Akhgari]

On 2017-03-16 2:29 PM, Bobby Holley wrote:
> On Thu, Mar 16, 2017 at 11:23 AM, R Kent James  wrote:
> 
>> 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?
>>
> 
> 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[Kris Maglione]

On Fri, Mar 17, 2017 at 11:44:08AM +0200, Henri Sivonen wrote:

On Thu, Mar 16, 2017 at 8:12 PM, Kris Maglione  wrote:

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


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.)


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.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[Henri Sivonen]

On Thu, Mar 16, 2017 at 8:12 PM, Kris Maglione  wrote:
> 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

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.)

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[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


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[Bobby Holley]

On Thu, Mar 16, 2017 at 11:23 AM, R Kent James  wrote:

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

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

Re: Tracking bug for removals after XPCOM extensions are no more?

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[Henri Sivonen]

On Thu, Mar 16, 2017 at 7:34 AM, Boris Zbarsky  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

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[Boris Zbarsky]

On 3/15/17 6:51 PM, Benjamin Smedberg wrote:

On Wed, Mar 15, 2017 at 4:24 PM, Boris Zbarsky  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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[Benjamin Smedberg]

On Wed, Mar 15, 2017 at 4:24 PM, Boris Zbarsky  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[Henri Sivonen]

On Wed, Mar 15, 2017 at 10:24 PM, Boris Zbarsky  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.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[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.



On Wed, Mar 15, 2017 at 8:00 AM, Henri Sivonen  wrote:

On Mon, Mar 13, 2017 at 3:17 PM, Nathan Froyd  wrote:

We do not.


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[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

On Wed, Mar 15, 2017 at 8:00 AM, Henri Sivonen  wrote:
> On Mon, Mar 13, 2017 at 3:17 PM, Nathan Froyd  wrote:
>> We do not.
>
> OK. I filed one:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1347507
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> 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

Re: Tracking bug for removals after XPCOM extensions are no more?

[Henri Sivonen]

On Mon, Mar 13, 2017 at 3:17 PM, Nathan Froyd  wrote:
> We do not.

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

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[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.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[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.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tracking bug for removals after XPCOM extensions are no more?

[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

On Fri, Mar 10, 2017 at 6:40 AM, Henri Sivonen  wrote:
> 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
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> 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

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
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform