Tails

#1 Updated by anonym 2019-03-19 10:03:18

• blocks Feature #15507: Core work 2019Q1: Foundations Team added

#2 Updated by anonym 2019-03-19 10:16:07

• Status changed from Confirmed to In Progress
• % Done changed from 0 to 10

This looks like a weird one:

• Both I and intri have reproduced it with Debian’s 1:60.5.1-1~deb9u1 (the bug expresses itself differently thanks to our patches, though) so our patches shouldn’t be the cause, but it seems like an upstream bug.
• However, in the same session where I reproduced the bug I tested an official Thunderbird build (actually both 60.5.1 and 60.5.3) and could not reproduce.
• I cannot reproduce at all in my Debian Stretch VM, and I tested a lot of versions: Debian’s 1:60.5.1-1~deb9u1, our 60.5.1-1~deb9u1.0tails1, official 60.5.[0-3] tarballs.

So we might have to look at our thunderbird wrapper and profile (addons, prefs) to try to find what is different and causing this problem.

Furthermore, when trying to track down that exception (in emailWizard.js), I can conclude that it is thrown in foundConfig(), immediately after this.displayConfigResult(config) returns. Even if I wrap all of displayConfigResult’s body in a try { } I cannot catch the exception in there, so there’s some async madness going on.

#3 Updated by anonym 2019-03-19 10:29:52

• related to Bug #16422: Upgrade Thunderbird to 60.5.1 added

#4 Updated by anonym 2019-03-20 08:40:12

• % Done changed from 10 to 40

The problem is caused by Torbirdy not yet having being adapted for Thunderbird 60.5.1, which is just a one line fix:

diff --git a/chrome/content/emailwizard.js b/chrome/content/emailwizard.js
index 8e2deea..63f668b 100644
--- a/chrome/content/emailwizard.js
+++ b/chrome/content/emailwizard.js
@@ -146,7 +146,7 @@ if(!org.torbirdy.emailwizard) org.torbirdy.emailwizard = new function() {
       var old_displayConfigResult = gEmailConfigWizard.displayConfigResult;
       gEmailConfigWizard.displayConfigResult = function(config) {
         old_displayConfigResult.call(this, config);
-        var radiogroup = document.getElementById("result_imappop");
+        var radiogroup = document.getElementById("result_servertype");
         if (radiogroup.hidden) {
           return;
         }

#5 Updated by anonym 2019-03-20 08:59:15

• Subject changed from Thunderbird ISP fetch broken since 60.5.1 to Thunderbird autoconfig broken since 60.5.1
• Type of work changed from Research to Wait

Upstream bug: https://trac.torproject.org/projects/tor/ticket/29829

#6 Updated by anonym 2019-03-20 09:21:45

• % Done changed from 40 to 50
• QA Check set to Ready for QA
• Feature Branch set to bugfix/16573-fix-thunderbird-autoconfig
• Type of work changed from Wait to Code

On second thought, let’s apply the fix in Tails now, so we have this fixed if there’s an emergency release soon or if it takes time to release a fixed Torbirdy package. This should be a Tails-only bug since it only affects Torbirdy users that uses Thunderbird’s default wizard, like we do. I seriously doubt any one else does it, and if they do they are already shooting themselves in the foot because they probably do not use our “secure autoconfig” patch series. So it’s fine to treat this as a Tails-only bug, IMHO.

#7 Updated by anonym 2019-03-20 10:41:33

• Feature Branch changed from bugfix/16573-fix-thunderbird-autoconfig to bugfix/16573-fix-thunderbird-autoconfig+force-all-tests

#8 Updated by intrigeri 2019-03-20 14:46:12

• blocks Feature #16209: Core work: Foundations Team added

#9 Updated by intrigeri 2019-03-20 14:46:26

• blocked by deleted (Feature #15507: Core work 2019Q1: Foundations Team)

#10 Updated by anonym 2019-03-21 12:15:09

• Assignee deleted (anonym)

Jenkins did 2/2 full runs without any failures related to Thunderbird.

Please review’n’merge!

Review hint: this is all about an element id change in Thunderbird’s comm/mail/components/accountcreation/content/emailWizard.js, which Torbirdy is referencing in chrome/content/emailwizard.js.

#11 Updated by intrigeri 2019-03-24 06:40:57

• Assignee set to CyrilBrulebois

@CyrilBrulebois, I think you’re the best placed to review this. Can you do so by the end of our upcoming FT sprint? (The earlier we provide feedback to anonym, the better: context-switching and WIP are Bad™ :)

#12 Updated by CyrilBrulebois 2019-04-02 13:20:41

• Assignee changed from CyrilBrulebois to anonym
• QA Check changed from Ready for QA to Pass

LGTM.

The radio button elements inside the group also got updated values (1→imap, 2→pop3) but given the code querying that in torbirdy, that shouldn’t make a difference:

var imap_element = document.getElementById("result_select_imap");
var pop_element = document.getElementById("result_select_pop3");
if (prefer_pop && imap_element.selected && pop_element) {
[…]

#13 Updated by intrigeri 2019-04-05 13:09:10

• QA Check changed from Pass to Dev Needed

#14 Updated by intrigeri 2019-04-09 06:57:35

• related to Bug #16641: Upgrade Thunderbird to 60.6.1-1~deb9u1 added

#16 Updated by intrigeri 2019-04-30 08:57:52

• Status changed from In Progress to Fix committed
• Assignee deleted (anonym)
• % Done changed from 50 to 100
• QA Check changed from Dev Needed to Pass

#17 Updated by intrigeri 2019-05-05 08:24:06

• Target version changed from Tails_3.14 to Tails_3.13.2

#18 Updated by anonym 2019-05-06 15:02:25

• Status changed from Fix committed to Resolved

#19 Updated by anonym 2019-05-06 15:03:19

• Target version changed from Tails_3.13.2 to Tails_3.14

#20 Updated by intrigeri 2019-05-06 18:15:44

• Target version changed from Tails_3.14 to Tails_3.13.2