On 06/14/2017 09:02 AM, Benjamin Smedberg wrote:
On Tue, Jun 13, 2017 at 8:40 PM, Nicholas Nethercote <n.netherc...@gmail.com
wrote:
(3) Do extensions use it? If so, changing it probably isn't possible. This
can
be imperfectly determined by searching through addons/ in DXR.
There is no rule that we can't break old-style addons: it just makes the
change riskier and may require outreach or an addon validation step. So
it's a question of risk/reward tradeoff.
Given that old-style addons are going away for 57, if it's possible to
delay addon-breaking IDL changes by one release until 57 that's probably
the easiest way to deal with this. We're already causing the addon
community a lot of churn.
Also note that not every kind of modification to IDL files has the same
kind of risk in terms of add-on (and also Thunderbird) breakage. For
example, adding a new method/attribute can very rarely break something
(unless for example code tests for existence of the currently
non-existing name and takes a different path based on that.) Similarly,
adding an optional argument at the end of the list of arguments to a
method can rarely break an add-on, except if the add-on implements the
method.
(Although, if DevTools are moved its their own repository, that repo will
have to be
checked as well?)
I've been trying to find out some technical details about the devtools
plan, but my initial understanding is that they are trying to target stable
web/webextensions/debugger API surfaces, and so they *shouldn't* be
affected by gecko internals changes. But I'd be a lot more comfortable if
that were in writing as part of the devtools plan.
(There's a google doc about the plans but I'm not sure if I'm allowed to
link to it here, someone from the devtools team can probably do so here
if that's OK...)
That sounds pretty hard to believe given how deeply tied devtools is
into Gecko. At least in a few areas that I'm familiar with, there are
no Web Extension APIs for what devtools needs, so it will most likely
need to depend on our XPCOM APIs at least in the immediate term.
Two items to add to njn's list:
[5] Pay attention to [builtinclass] interfaces (and make new ones where
possible!)
builtinclass means that JS code isn't allowed to implement an XPIDL
interface, which allows C++ code to assume things about the concrete
implementation behind an XPIDL interface which can sometimes be nice.
If you are modifying a [builtinclass] interface for example to add a new
argument to a method, you don't need to worry about add-ons implementing
that method, since that would be impossible. Where possible and
sensible, please try to make existing interfaces [builtinclass].
[6] Note that it's not clear yet how we will be able to remove XPCOM
APIs post-57 due to the existence of WebExtensions Experiments
<https://webextensions-experiments.readthedocs.io/en/latest/>. I'm not
sure who's going to make the call on which APIs we'd want to retain for
those WebExtensions and which APIs we'd want to freely modify/remove
after 57.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
