Don't display the Enigmail setup wizard by default when starting Thunderbird
We did not display it before Tails 3.8 (in line with the decision made on #10436) but Tails 3.8 displays it. It should not.
Don't display the Enigmail setup wizard by default when starting Thunderbird (refs: #15746)
Suppress Enigmail's configuration wizard by pretending that the current version
was already configured. Only do this on first run though: once we've done this
we let Enigmail manage this setting itself so it can run any migration code it
wants to on upgrades.
#4 Updated by intrigeri about 2 months ago
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 10
- Feature Branch set to bugfix/15746-hide-enigmail-config-wizard
I think we want to set
extensions.enigmail.configuredVersion to the current version if, and only if, the Thunderbird profile was not initialized yet. This way, in theory:
- when starting Thunderbird for the first time, the wizard won't be displayed; I've claimed the opposite in 5a5cab28cd481be4cf71bd130a5241bc07400d0e so I'll need to re-check what's going on
- once the user has started Thunderbird, Enigmail stores its current version number in the pref, so on following runs Enigmail will only display dialogs if it has a specific upgrade path (from the configuredVersion to the current version) that needs user interaction, which should only happen on upgrades and very rarely (my understanding of the code says that only the upgrade from < 1.7 triggers this currently; that was 4 years ago)
- I see no code that can fire up the wizard upon upgrades so once we've fully disabled it on startup, the only ways for users to configure Enigmail will be to start the setup wizard themselves, just like before Tails 3.8
#5 Updated by intrigeri about 2 months ago
- Assignee changed from intrigeri to segfault
- % Done changed from 10 to 50
- Estimated time set to 1.00 h
- QA Check set to Ready for QA
Implemented, seems to work fine. It would be great if you could test it in various scenarios (persistent profile created with 3.8, persistent profile created on an ISO built from this branch, non-persistent profile), hence the higher time allocation than usual for a simple code change. But frankly I don't think you'll use all the budget.