TB 61: Bootstrapped manifest not allowed to use 'resource' directive
It looks like TB 61 does not allow resource:// URLs for bootstrapped
addons anymore. I got the following error after updating to TB 61.0a1
(2018-03-21):
Bootstrapped manifest not allowed to use 'resource' directive.
chrome.manifest:26
The content of line 26 in chrome.manifest is this:
resource enigmail modules/
This will probably break most TB addons entirely :-(
-Patrick
On 22/03/2018 08:18, Patrick Brunschwig wrote:
This will probably break most TB addons entirely
Looks like this comes from here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1446585
Landed on 21st March and included in the Daily of that day.
Jörg.
On 22.03.18 11:07, Jörg Knobloch wrote:
On 22/03/2018 08:18, Patrick Brunschwig wrote:
This will probably break most TB addons entirely
Looks like this comes from here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1446585
Landed on 21st March and included in the Daily of that day.
What's the suggested way forward here? In theory, addons could load
resources from anywhere else, for example from .../content/resource/.
That would be ugly, but would probably work in the short term.
But I think it really demonstrates that if we want to keep addons in TB,
then we need to find a way to make WebExtensions usable for TB-specifics.
-Patrick
On 22/03/2018 12:23, Patrick Brunschwig wrote:
<pre class="moz-quote-pre" wrap="">But I think it really demonstrates that if we want to keep addons in TB, then we need to find a way to make WebExtensions usable for TB-specifics.
I could be that TB 60 ESR will the the last version to support add-ons as we know them.
M-C are moving to doing the following:
- Remove XUL overlays, basis of most add-ons
- Remove support for non-restartless add-ons (to my knowledge, there are only a few bootstrapped add-ons), including [Bug 1447831] Remove front-end support for non-restartless add-ons.
So it's getting really tight and we're already dedicating too many resourced to keeping add-ons alive.
No official statement, just my 2 cents worth.
Jörg.
May I ask: Why don't we do a hard fork than, so we no longer depend on
what "they" are doing (if everything they do is killing us).
Thanks,
John
Am 22.03.2018 um 20:53 schrieb Jörg Knobloch:
On 22/03/2018 12:23, Patrick Brunschwig wrote:
But I think it really demonstrates that if we want to keep addons in TB,
then we need to find a way to make WebExtensions usable for TB-specifics.
I could be that TB 60 ESR will the the last version to support add-ons
as we know them.
M-C are moving to doing the following:
- Remove XUL overlays, basis of most add-ons
- Remove support for non-restartless add-ons (to my knowledge, there
are only a few bootstrapped add-ons), including [Bug 1447831]
Remove front-end support for non-restartless add-ons.
So it's getting really tight and we're already dedicating too many
resourced to keeping add-ons alive.
No official statement, just my 2 cents worth.
Jörg.
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
On 22/03/2018 21:14, John Bieling wrote:
May I ask: Why don't we do a hard fork than, so we no longer depend on
what "they" are doing (if everything they do is killing us).
That question has been asked many times and has been answered many times.
TB 60 is being built as beta at time of writing and will go to ESR in
May and will live there for about one year receiving security updates.
From mid-2019 the 60 ESR branch will be unmaintained and will not
receive any security updates. The next exploit/vulnerability will then
make TB 60 ESR unsecure starting mid-2019.
We don't have the manpower to do security fixes ourselves, so we need to
rely on the underlying Mozilla platform to be secure. Hence we need to
follow Mozilla wherever they are going or switch to a different platform.
That said, it would be nice to be in a situation where we don't spend a
lot of time following the changes of the underlying platform. One day we
will get there, but currently Mozilla is in the process of restructuring
and we feel the effects every day.
It has been discussed to fork part of the technology we're currently
using and only follow the Mozilla platform for the part that is exposed
to security threats, that's mainly the HTML rendering in e-mail, JS
execution, etc.
Jörg.
Thank you Jörg, for the details and thanks for your time to answer this
and my other questions.
John
Am 23.03.2018 um 19:43 schrieb Jörg Knobloch:
On 22/03/2018 21:14, John Bieling wrote:
May I ask: Why don't we do a hard fork than, so we no longer depend
on what "they" are doing (if everything they do is killing us).
That question has been asked many times and has been answered many times.
TB 60 is being built as beta at time of writing and will go to ESR in
May and will live there for about one year receiving security updates.
From mid-2019 the 60 ESR branch will be unmaintained and will not
receive any security updates. The next exploit/vulnerability will then
make TB 60 ESR unsecure starting mid-2019.
We don't have the manpower to do security fixes ourselves, so we need
to rely on the underlying Mozilla platform to be secure. Hence we need
to follow Mozilla wherever they are going or switch to a different
platform.
That said, it would be nice to be in a situation where we don't spend
a lot of time following the changes of the underlying platform. One
day we will get there, but currently Mozilla is in the process of
restructuring and we feel the effects every day.
It has been discussed to fork part of the technology we're currently
using and only follow the Mozilla platform for the part that is
exposed to security threats, that's mainly the HTML rendering in
e-mail, JS execution, etc.
Jörg.
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
On 22.03.18 20:53, Jörg Knobloch wrote:
On 22/03/2018 12:23, Patrick Brunschwig wrote:
But I think it really demonstrates that if we want to keep addons in TB,
then we need to find a way to make WebExtensions usable for TB-specifics.
I could be that TB 60 ESR will the the last version to support add-ons
as we know them.
M-C are moving to doing the following:
- Remove XUL overlays, basis of most add-ons
- Remove support for non-restartless add-ons (to my knowledge, there
are only a few bootstrapped add-ons), including [Bug 1447831] Remove
front-end support for non-restartless add-ons.
This is why I converted Enigmail into a bootstrapped addon (which was
quite a substantial work).
I fixed the resource:// issue by moving everything to
chrome://.../content/... . Not nice, but working.
-Patrick
Just a short note, it should still be possible to use nsIResProtocolHandler to set a substitution as you would in the manifest.
Ideally we can undo this change in a non-invasive way though, and should be looking into an api that is more stable, like WebExtensions.
Philipp
On 24. Mar 2018, at 10:56 AM, Patrick Brunschwig patrick@enigmail.net wrote:
On 22.03.18 20:53, Jörg Knobloch wrote:
On 22/03/2018 12:23, Patrick Brunschwig wrote:
But I think it really demonstrates that if we want to keep addons in TB,
then we need to find a way to make WebExtensions usable for TB-specifics.
I could be that TB 60 ESR will the the last version to support add-ons
as we know them.
M-C are moving to doing the following:
- Remove XUL overlays, basis of most add-ons
- Remove support for non-restartless add-ons (to my knowledge, there
are only a few bootstrapped add-ons), including [Bug 1447831] Remove
front-end support for non-restartless add-ons.
This is why I converted Enigmail into a bootstrapped addon (which was
quite a substantial work).
I fixed the resource:// issue by moving everything to
chrome://.../content/... . Not nice, but working.
-Patrick
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net