Project

General

Profile

Bug #16573

Thunderbird autoconfig broken since 60.5.1

Added by anonym 6 months ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
03/19/2019
Due date:
% Done:

100%

Feature Branch:
bugfix/16573-fix-thunderbird-autoconfig+force-all-tests
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Email Client

Description

Since moving to Thunderbird 50.5.1 (which introduces parallel autoconfig), during autoconfiguration, if the ISP fetch succeeds then the result is shown and all looks good for a second, but then a mysterious exception (TypeError: radiogroup is null) is thrown which then turns it into a failure, and we throw away the results and start protocol guessing.

More background:


Related issues

Related to Tails - Bug #16422: Upgrade Thunderbird to 60.5.1 Resolved 02/05/2019
Related to Tails - Bug #16641: Upgrade Thunderbird to 60.6.1-1~deb9u1 Resolved
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

Associated revisions

Revision 11d5f5c1 (diff)
Added by anonym 6 months ago

Torbirdy: sync element id that changed in upstream Thunderbird.

Will-fix: #16573

Revision 15440a59 (diff)
Added by anonym 6 months ago

Torbirdy: sync element id that changed in upstream Thunderbird.

Will-fix: #16573

History

#1 Updated by anonym 6 months ago

#2 Updated by anonym 6 months ago

  • 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 6 months ago

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

#4 Updated by anonym 6 months ago

  • % 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 6 months ago

  • 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

#6 Updated by anonym 6 months ago

  • % 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 6 months ago

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

#8 Updated by intrigeri 6 months ago

#9 Updated by intrigeri 6 months ago

#10 Updated by anonym 6 months ago

  • 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 6 months ago

  • 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 6 months ago

  • 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 5 months ago

  • QA Check changed from Pass to Dev Needed

#14 Updated by intrigeri 5 months ago

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

#15 Updated by intrigeri 5 months ago

With 1:60.6.1-1~deb9u1.0tails1, Thunderbird fails to auto-detect the correct servers for a boum.org address, while https://boum.org/.well-known/autoconfig/mail/config-v1.1.xml LGTM.

Applying the Torbirdy patch added in this branch fixes the problem for me: the config from the ISP's autoconfig is used and works fine.

kibi has marked this as QA Pass so I'll merge this.

I don't understand kibi's comment above but given he wrote "that shouldn't make a difference", I'll simply ignore it.

#16 Updated by intrigeri 5 months ago

  • 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 4 months ago

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

#18 Updated by anonym 4 months ago

  • Status changed from Fix committed to Resolved

#19 Updated by anonym 4 months ago

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

#20 Updated by intrigeri 4 months ago

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

Also available in: Atom PDF