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