maildev@lists.thunderbird.net

Thunderbird email developers

View all threads

Though problems facing TB 59

JK
Jörg Knobloch
Sun, Nov 26, 2017 3:51 PM

Hi Engineering Steering Committee:

What are our plans to address the following problems?

Thunderbird is currently hanging by a thin silken thread of
|pref("jsloader.shareGlobal", false);| which is an untested option that
M-C can withdraw any minute (although such plans don't currently exist).

The background is that M-C switched to using a "single compartment" for
all globals in https://bugzilla.mozilla.org/show_bug.cgi?id=1186409 and
there were about 30 bugs (blocking that bug) that had to be fixed to
make it happen.

With the preference at its default value, TB just collapses with
hundreds of test failures. We're tracking the work required in TB in
https://bugzilla.mozilla.org/show_bug.cgi?id=1401528, but after fixing
some easy issues, the bug has lost momentum. I can't even get review for
a patch that would address the issue in JS Mime.

The next very sore point that makes TB 59 Daily unusable for people who
want to use some add-ons is the fact that default preferences and inline
options don't work in TB 58 and TB 59. I got TB 58 beta to work with a
backout, but that's now a way forward.

We're tracking default preferences in
https://bugzilla.mozilla.org/show_bug.cgi?id=1414398 and inline options
in https://bugzilla.mozilla.org/show_bug.cgi?id=1419145. Note that the
official way to get inline options, is to embed a WebExtension, but
that's sadly also blocked by
https://bugzilla.mozilla.org/show_bug.cgi?id=1418914.

So unless we plan to fix these bugs, their solution will be left to
chance, like has happened to so many other "tough" problems (removal of
compose windows recycling, Asian crisis (CJK text destroyed by spurious
spaces, also injected into the middle of multi-byte characters),
migration to cache2, implementation of async proxies, Outlook import,
just to name a few). While TB was limping along with those bugs unfixed,
not fixing the globals and the add-ons issue is not optional and will
crash-land the bird.

Jörg.

P.S.: I could mention that nsIURI and friends is now "built-in",
smashing right through our JS Account code, but not fixing that will
just mean that ExQuilla will stop working in TB 59.

BTW, TB 59 is going to beta in at the end of January 2018 and going to
ESR in March 2018.

Hi Engineering Steering Committee: What are our plans to address the following problems? Thunderbird is currently hanging by a thin silken thread of |pref("jsloader.shareGlobal", false);| which is an untested option that M-C can withdraw any minute (although such plans don't currently exist). The background is that M-C switched to using a "single compartment" for all globals in https://bugzilla.mozilla.org/show_bug.cgi?id=1186409 and there were about 30 bugs (blocking that bug) that had to be fixed to make it happen. With the preference at its default value, TB just collapses with hundreds of test failures. We're tracking the work required in TB in https://bugzilla.mozilla.org/show_bug.cgi?id=1401528, but after fixing some easy issues, the bug has lost momentum. I can't even get review for a patch that would address the issue in JS Mime. The next very sore point that makes TB 59 Daily unusable for people who want to use some add-ons is the fact that default preferences and inline options don't work in TB 58 and TB 59. I got TB 58 beta to work with a backout, but that's now a way forward. We're tracking default preferences in https://bugzilla.mozilla.org/show_bug.cgi?id=1414398 and inline options in https://bugzilla.mozilla.org/show_bug.cgi?id=1419145. Note that the official way to get inline options, is to embed a WebExtension, but that's sadly also blocked by https://bugzilla.mozilla.org/show_bug.cgi?id=1418914. So unless we plan to fix these bugs, their solution will be left to chance, like has happened to so many other "tough" problems (removal of compose windows recycling, Asian crisis (CJK text destroyed by spurious spaces, also injected into the middle of multi-byte characters), migration to cache2, implementation of async proxies, Outlook import, just to name a few). While TB was limping along with those bugs unfixed, not fixing the globals and the add-ons issue is *not optional* and will crash-land the bird. Jörg. P.S.: I could mention that nsIURI and friends is now "built-in", smashing right through our JS Account code, but not fixing that will just mean that ExQuilla will stop working in TB 59. BTW, TB 59 is going to beta in at the end of January 2018 and going to ESR in March 2018.
BB
Ben Bucksch
Mon, Nov 27, 2017 8:34 PM

Hey Jörg,

for an ordered discussion, could you please limit it to one problem per
thread?

Also, a little more background for each issue would be helpful.

E.g. for the first one: What's a JS compartment, in contrast to a JS
scope? Given that scopes are still separate. Why does TB fail when the
compartment is global, what's the underlying root cause? Redefinition of
types that are defined separately in 2 JSMs? Is the shareGlobal only a
temporary pref until things stablize?

Even if some of the above can be googled or is linked in the bugs you
cited, please don't assume that we'll all dig deep and do research, but
present the problem in the most consumable form for the readers.

If we all understand the problem, maybe somebody has good idea for a
solution.

Ben

Jörg Knobloch wrote on 26.11.17 16:51:

Hi Engineering Steering Committee:

What are our plans to address the following problems?

Thunderbird is currently hanging by a thin silken thread of
|pref("jsloader.shareGlobal", false);| which is an untested option
that M-C can withdraw any minute (although such plans don't currently
exist).

The background is that M-C switched to using a "single compartment"
for all globals in
https://bugzilla.mozilla.org/show_bug.cgi?id=1186409 and there were
about 30 bugs (blocking that bug) that had to be fixed to make it happen.

With the preference at its default value, TB just collapses with
hundreds of test failures. We're tracking the work required in TB in
https://bugzilla.mozilla.org/show_bug.cgi?id=1401528, but after fixing
some easy issues, the bug has lost momentum. I can't even get review
for a patch that would address the issue in JS Mime.

The next very sore point that makes TB 59 Daily unusable for people
who want to use some add-ons is the fact that default preferences and
inline options don't work in TB 58 and TB 59. I got TB 58 beta to work
with a backout, but that's now a way forward.

We're tracking default preferences in
https://bugzilla.mozilla.org/show_bug.cgi?id=1414398 and inline
options in https://bugzilla.mozilla.org/show_bug.cgi?id=1419145. Note
that the official way to get inline options, is to embed a
WebExtension, but that's sadly also blocked by
https://bugzilla.mozilla.org/show_bug.cgi?id=1418914.

So unless we plan to fix these bugs, their solution will be left to
chance, like has happened to so many other "tough" problems (removal
of compose windows recycling, Asian crisis (CJK text destroyed by
spurious spaces, also injected into the middle of multi-byte
characters), migration to cache2, implementation of async proxies,
Outlook import, just to name a few). While TB was limping along with
those bugs unfixed, not fixing the globals and the add-ons issue is
not optional and will crash-land the bird.

Jörg.

P.S.: I could mention that nsIURI and friends is now "built-in",
smashing right through our JS Account code, but not fixing that will
just mean that ExQuilla will stop working in TB 59.

BTW, TB 59 is going to beta in at the end of January 2018 and going to
ESR in March 2018.


Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

Hey Jörg, for an ordered discussion, could you please limit it to one problem per thread? Also, a little more background for each issue would be helpful. E.g. for the first one: What's a JS compartment, in contrast to a JS scope? Given that scopes are still separate. Why does TB fail when the compartment is global, what's the underlying root cause? Redefinition of types that are defined separately in 2 JSMs? Is the shareGlobal only a temporary pref until things stablize? Even if some of the above can be googled or is linked in the bugs you cited, please don't assume that we'll all dig deep and do research, but present the problem in the most consumable form for the readers. If we all understand the problem, maybe somebody has good idea for a solution. Ben Jörg Knobloch wrote on 26.11.17 16:51: > Hi Engineering Steering Committee: > > What are our plans to address the following problems? > > Thunderbird is currently hanging by a thin silken thread of > |pref("jsloader.shareGlobal", false);| which is an untested option > that M-C can withdraw any minute (although such plans don't currently > exist). > > The background is that M-C switched to using a "single compartment" > for all globals in > https://bugzilla.mozilla.org/show_bug.cgi?id=1186409 and there were > about 30 bugs (blocking that bug) that had to be fixed to make it happen. > > With the preference at its default value, TB just collapses with > hundreds of test failures. We're tracking the work required in TB in > https://bugzilla.mozilla.org/show_bug.cgi?id=1401528, but after fixing > some easy issues, the bug has lost momentum. I can't even get review > for a patch that would address the issue in JS Mime. > > The next very sore point that makes TB 59 Daily unusable for people > who want to use some add-ons is the fact that default preferences and > inline options don't work in TB 58 and TB 59. I got TB 58 beta to work > with a backout, but that's now a way forward. > > We're tracking default preferences in > https://bugzilla.mozilla.org/show_bug.cgi?id=1414398 and inline > options in https://bugzilla.mozilla.org/show_bug.cgi?id=1419145. Note > that the official way to get inline options, is to embed a > WebExtension, but that's sadly also blocked by > https://bugzilla.mozilla.org/show_bug.cgi?id=1418914. > > So unless we plan to fix these bugs, their solution will be left to > chance, like has happened to so many other "tough" problems (removal > of compose windows recycling, Asian crisis (CJK text destroyed by > spurious spaces, also injected into the middle of multi-byte > characters), migration to cache2, implementation of async proxies, > Outlook import, just to name a few). While TB was limping along with > those bugs unfixed, not fixing the globals and the add-ons issue is > *not optional* and will crash-land the bird. > > Jörg. > > P.S.: I could mention that nsIURI and friends is now "built-in", > smashing right through our JS Account code, but not fixing that will > just mean that ExQuilla will stop working in TB 59. > > BTW, TB 59 is going to beta in at the end of January 2018 and going to > ESR in March 2018. > > > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net > >
JK
Jörg Knobloch
Mon, Nov 27, 2017 8:40 PM

On 27/11/2017 21:34, Ben Bucksch wrote:

E.g. for the first one: What's a JS compartment, in contrast to a JS
scope? Given that scopes are still separate. Why does TB fail when the
compartment is global, what's the underlying root cause? Redefinition
of types that are defined separately in 2 JSMs? Is the shareGlobal
only a temporary pref until things stablize?

The global scope bug has gained momentum again, Aceman picked it up.

That leaves the add-on issues which make TB 59 Daily pretty useless so
far. Some planning is required here.

Jörg.

On 27/11/2017 21:34, Ben Bucksch wrote: > E.g. for the first one: What's a JS compartment, in contrast to a JS > scope? Given that scopes are still separate. Why does TB fail when the > compartment is global, what's the underlying root cause? Redefinition > of types that are defined separately in 2 JSMs? Is the shareGlobal > only a temporary pref until things stablize? The global scope bug has gained momentum again, Aceman picked it up. That leaves the add-on issues which make TB 59 Daily pretty useless so far. Some *planning* is required here. Jörg.
MM
Magnus Melin
Mon, Nov 27, 2017 8:58 PM

https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security#Compartments

To understand it, and what it means in practice for our code requires a
lot of time and investigation.
It's great the bug is progressing and had input from many collaborators.
For bugs like these where there are many places to fix and the solution
varies from place to place it's no surprise there aren't that many eager
takers... it's a substantial time investment to fix.

 -Magnus

On 27-11-2017 22:34, Ben Bucksch wrote:

Hey Jörg,

for an ordered discussion, could you please limit it to one problem
per thread?

Also, a little more background for each issue would be helpful.

E.g. for the first one: What's a JS compartment, in contrast to a JS
scope? Given that scopes are still separate. Why does TB fail when the
compartment is global, what's the underlying root cause? Redefinition
of types that are defined separately in 2 JSMs? Is the shareGlobal
only a temporary pref until things stablize?

Even if some of the above can be googled or is linked in the bugs you
cited, please don't assume that we'll all dig deep and do research,
but present the problem in the most consumable form for the readers.

If we all understand the problem, maybe somebody has good idea for a
solution.

Ben

Jörg Knobloch wrote on 26.11.17 16:51:

Hi Engineering Steering Committee:

What are our plans to address the following problems?

Thunderbird is currently hanging by a thin silken thread of
|pref("jsloader.shareGlobal", false);| which is an untested option
that M-C can withdraw any minute (although such plans don't currently
exist).

The background is that M-C switched to using a "single compartment"
for all globals in
https://bugzilla.mozilla.org/show_bug.cgi?id=1186409 and there were
about 30 bugs (blocking that bug) that had to be fixed to make it
happen.

With the preference at its default value, TB just collapses with
hundreds of test failures. We're tracking the work required in TB in
https://bugzilla.mozilla.org/show_bug.cgi?id=1401528, but after
fixing some easy issues, the bug has lost momentum. I can't even get
review for a patch that would address the issue in JS Mime.

The next very sore point that makes TB 59 Daily unusable for people
who want to use some add-ons is the fact that default preferences and
inline options don't work in TB 58 and TB 59. I got TB 58 beta to
work with a backout, but that's now a way forward.

We're tracking default preferences in
https://bugzilla.mozilla.org/show_bug.cgi?id=1414398 and inline
options in https://bugzilla.mozilla.org/show_bug.cgi?id=1419145. Note
that the official way to get inline options, is to embed a
WebExtension, but that's sadly also blocked by
https://bugzilla.mozilla.org/show_bug.cgi?id=1418914.

So unless we plan to fix these bugs, their solution will be left to
chance, like has happened to so many other "tough" problems (removal
of compose windows recycling, Asian crisis (CJK text destroyed by
spurious spaces, also injected into the middle of multi-byte
characters), migration to cache2, implementation of async proxies,
Outlook import, just to name a few). While TB was limping along with
those bugs unfixed, not fixing the globals and the add-ons issue is
not optional and will crash-land the bird.

Jörg.

P.S.: I could mention that nsIURI and friends is now "built-in",
smashing right through our JS Account code, but not fixing that will
just mean that ExQuilla will stop working in TB 59.

BTW, TB 59 is going to beta in at the end of January 2018 and going
to ESR in March 2018.


Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security#Compartments To understand it, and what it means in practice for our code requires a lot of time and investigation. It's great the bug is progressing and had input from many collaborators. For bugs like these where there are many places to fix and the solution varies from place to place it's no surprise there aren't that many eager takers... it's a substantial time investment to fix.  -Magnus On 27-11-2017 22:34, Ben Bucksch wrote: > Hey Jörg, > > for an ordered discussion, could you please limit it to one problem > per thread? > > Also, a little more background for each issue would be helpful. > > E.g. for the first one: What's a JS compartment, in contrast to a JS > scope? Given that scopes are still separate. Why does TB fail when the > compartment is global, what's the underlying root cause? Redefinition > of types that are defined separately in 2 JSMs? Is the shareGlobal > only a temporary pref until things stablize? > > Even if some of the above can be googled or is linked in the bugs you > cited, please don't assume that we'll all dig deep and do research, > but present the problem in the most consumable form for the readers. > > If we all understand the problem, maybe somebody has good idea for a > solution. > > Ben > > Jörg Knobloch wrote on 26.11.17 16:51: >> Hi Engineering Steering Committee: >> >> What are our plans to address the following problems? >> >> Thunderbird is currently hanging by a thin silken thread of >> |pref("jsloader.shareGlobal", false);| which is an untested option >> that M-C can withdraw any minute (although such plans don't currently >> exist). >> >> The background is that M-C switched to using a "single compartment" >> for all globals in >> https://bugzilla.mozilla.org/show_bug.cgi?id=1186409 and there were >> about 30 bugs (blocking that bug) that had to be fixed to make it >> happen. >> >> With the preference at its default value, TB just collapses with >> hundreds of test failures. We're tracking the work required in TB in >> https://bugzilla.mozilla.org/show_bug.cgi?id=1401528, but after >> fixing some easy issues, the bug has lost momentum. I can't even get >> review for a patch that would address the issue in JS Mime. >> >> The next very sore point that makes TB 59 Daily unusable for people >> who want to use some add-ons is the fact that default preferences and >> inline options don't work in TB 58 and TB 59. I got TB 58 beta to >> work with a backout, but that's now a way forward. >> >> We're tracking default preferences in >> https://bugzilla.mozilla.org/show_bug.cgi?id=1414398 and inline >> options in https://bugzilla.mozilla.org/show_bug.cgi?id=1419145. Note >> that the official way to get inline options, is to embed a >> WebExtension, but that's sadly also blocked by >> https://bugzilla.mozilla.org/show_bug.cgi?id=1418914. >> >> So unless we plan to fix these bugs, their solution will be left to >> chance, like has happened to so many other "tough" problems (removal >> of compose windows recycling, Asian crisis (CJK text destroyed by >> spurious spaces, also injected into the middle of multi-byte >> characters), migration to cache2, implementation of async proxies, >> Outlook import, just to name a few). While TB was limping along with >> those bugs unfixed, not fixing the globals and the add-ons issue is >> *not optional* and will crash-land the bird. >> >> Jörg. >> >> P.S.: I could mention that nsIURI and friends is now "built-in", >> smashing right through our JS Account code, but not fixing that will >> just mean that ExQuilla will stop working in TB 59. >> >> BTW, TB 59 is going to beta in at the end of January 2018 and going >> to ESR in March 2018. >> >> >> >> _______________________________________________ >> Maildev mailing list >> Maildev@lists.thunderbird.net >> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net >> >> > > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net >
JK
Jörg Knobloch
Mon, Nov 27, 2017 9:17 PM

On 27/11/2017 21:58, Magnus Melin wrote:

https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security#Compartments

To understand it, and what it means in practice for our code requires
a lot of time and investigation.
It's great the bug is progressing and had input from many
collaborators. For bugs like these where there are many places to fix
and the solution varies from place to place it's no surprise there
aren't that many eager takers... it's a substantial time investment to
fix.

The whole idea of guaranteeing a secure future of TB is some planning.
We can't rely on eager takers and chance.

Luckily Aceman appears to be on top of it. With three patches currently
in the way, the remaining failures come down to heaps of calendar
failures, which most likely have a common cause, and some seven failures
in mailnews/compose/test/unit/test_PasswordFailure.js, which also most
likely have a common cause. So that brings us down to three patches to
review/land and two problems to investigate.

Jörg.

On 27/11/2017 21:58, Magnus Melin wrote: > https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/Script_security#Compartments > > > To understand it, and what it means in practice for our code requires > a lot of time and investigation. > It's great the bug is progressing and had input from many > collaborators. For bugs like these where there are many places to fix > and the solution varies from place to place it's no surprise there > aren't that many eager takers... it's a substantial time investment to > fix. The whole idea of guaranteeing a secure future of TB is some planning. We can't rely on eager takers and chance. Luckily Aceman appears to be on top of it. With three patches currently in the way, the remaining failures come down to heaps of calendar failures, which most likely have a common cause, and some seven failures in mailnews/compose/test/unit/test_*PasswordFailure*.js, which also most likely have a common cause. So that brings us down to three patches to review/land and two problems to investigate. Jörg.
BB
Ben Bucksch
Wed, Nov 29, 2017 9:45 PM

Jörg Knobloch wrote on 27.11.17 22:17:

Luckily Aceman appears to be on top of it. ... So that brings us down
to three patches to review/land and two problems to investigate.

That's great news. Thanks, aceman!

Jörg Knobloch wrote on 27.11.17 22:17: > Luckily Aceman appears to be on top of it. ... So that brings us down > to three patches to review/land and two problems to investigate. That's great news. Thanks, aceman!
A
ace
Wed, Nov 29, 2017 9:54 PM

----- Pôvodná správa -----
Predmet: Re: [Maildev] Though problems facing TB 59
Od: Ben Bucksch ben.bucksch@beonex.com
Pre: maildev@lists.thunderbird.net, aceman acelists@atlas.sk
Dátum: Wed, 29 Nov 2017 22:45:44 +0100

Jörg Knobloch wrote on 27.11.17 22:17:

Luckily Aceman appears to be on top of it. ... So that brings us down
to three patches to review/land and two problems to investigate.

That's great news. Thanks, aceman!

2 of them landed today :)

So there is some last problem remaining with a mock window and some
faked dialogs in xpcshell tests. We played with it with arai, but we
have no sign of progress yet.

And then one problem in calendar which I'd expect Fallen can finish.

----- Pôvodná správa ----- Predmet: Re: [Maildev] Though problems facing TB 59 Od: Ben Bucksch <ben.bucksch@beonex.com> Pre: maildev@lists.thunderbird.net, aceman <acelists@atlas.sk> Dátum: Wed, 29 Nov 2017 22:45:44 +0100 > Jörg Knobloch wrote on 27.11.17 22:17: >> Luckily Aceman appears to be on top of it. ... So that brings us down >> to three patches to review/land and two problems to investigate. > > > That's great news. Thanks, aceman! 2 of them landed today :) So there is some last problem remaining with a mock window and some faked dialogs in xpcshell tests. We played with it with arai, but we have no sign of progress yet. And then one problem in calendar which I'd expect Fallen can finish.