Open Bug 1673280 Opened 4 years ago Updated 1 year ago

Add-on calendars change visibility on restarts and updates

Categories

(Calendar :: Internal Components, defect, P2)

Product:
Calendar
Component:
Internal Components
Version:
Thunderbird 78
Type:
defect

Tracking

(thunderbird_esr78+ wontfix)

Tracking Flags:
Tracking Status
thunderbird_esr78 + wontfix

People

(Reporter: public, Unassigned)

References

Details

(Whiteboard: [datalossy])

The visibility of Calendars created in add-ons may change on restarts and updates.

STR

  1. Thunderbird 102.10.0, clean profile
  2. Install the birthday calendar add-on from https://github.com/rsjtdrjgfuzkfg/thunderbird-birthdaycalendar/releases/download/v1.1/birthdaycalendar.xpi
  3. Observe that two calendars were created (for the default address books), which are visible
  4. Hide one of the two calendars observed in step 2
  5. Quit Thunderbird by closing the main window
  6. Start Thunderbird again and look in the calendar tab
  7. Hide the calendar observed in step 2, which was not hidden in step 3
  8. Update the add-on (just reinstall the same thing) and look in the calendar tab

Expected:

In steps 5 one calendar is hidden, in step 7 two calendars are hidden.

Actual:

In steps 5 and 7, both calendars are visible.

Original STR / Analysis

The following information applies to the original version of the bug that also had a probability to switch the visibility from visible to invisible, but seems to no longer reproduce (at least in the few test runs I did) and has been worked around in all current add-ons.

Information below this line might be outdated!

STR:

  1. Clean Profile, Thunderbird 78.4.0
  2. Install the Birthday Calendar Add-on from https://github.com/rsjtdrjgfuzkfg/thunderbird-birthdaycalendar/releases/download/v0.2/birthdaycalendar.xpi
  3. Observe that two calendars were created (for the default address books), which are visible
  4. Quit Thunderbird through the menu bar (Alt to show, then File | Quit)
  5. Start Thunderbird again and look in the calendar tab
  6. Update the add-on (just reinstall the same thing) and look in the calendar tab

Expected:

Both calendars remain enabled throughout.

Actual:

Both calendars are disabled in step 4 (not certain if this STR is reliable in all configurations, if in doubt try Linux x64 with the official build of 78.4.0) and re-enabled in step 5.

Cause:

While calendars registered before startup re-use their previous visibility, dummy calendars are force-disabled, while newly registered calendar types are force-enabled. The following section gives a step-by-step rundown on what happens:

On shutdown, there is a chance that the add-on is unloaded before Thunderbird exits. In that case, it is removed from the composite calendar
(CalCompositeCalendar.jsm line 176ff):

   if (newCalendars.length != this.mCalendars) {
      this.mCalendars = newCalendars;
      if (this.mPrefPrefix) {
        aCalendar.deleteProperty(this.mActivePref);

The comparison does not make sense (should probably be newCalendars.length != this.mCalendars.length), but that has nothing to do with the issue. Important to note is that the active property gets cleared.

The calendar is then not re-added, as its replacement is a disabled dummy calendar (compare calendar-management.js line 449ff, quoted in the last step).

After the restart, the calendar is registered before the composite calendar loaded. It is then added as invisible, as its active property is still null (CalCompositeCalendar.jsm line 136ff):

    cals.forEach(function(calendar) {
      if (calendar.getProperty(this.mActivePref)) {
        this.addCalendar(calendar);

Reloading the add-on replaces the calendar with a dummy (still invisible) and the new implementation (now becoming visible, as the calendar is no longer disabled, calendar-management.js line 449ff):

      let inComposite = calendar.getProperty("calendar-main-in-composite");
      if (inComposite === null && !calendar.getProperty("disabled")) {
        compositeCalendar.addCalendar(calendar);

Potential fixes

I'm unsure how to fix this properly. The best option I came up with would be to update the calendar manager to copy visibility information to a different property before unregistering a calendar type, and restoring it after re-registering. The same approach could also be used from an WebExtension Experiment as a workaround.

Summary: Calendars added by add-ons are hidden after restart → Add-on calendars change visibility on restarts and updates

I expect some of the duplicates closed on this bug are actually bug 1679723: in that bug, calendars are hidden after restarts without them becoming marked as invisible.

Could you look into this please Philipp? That'd be much faster than me trying to figure out how add-on calendars work.

Severity: -- → S2
Flags: needinfo?(philipp)
Priority: -- → P2

Calling it a dupe of bug 1679723. The duplicates have dried up after that bug was fixed.

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(philipp)
Resolution: --- → DUPLICATE

Not a dupe, still reproduces on 78.11 (with the same STR, but it might have gotten a bit less reliable: try multiple restarts if it does not reproduce).

Note that current versions of some add-ons have workarounds, it is essential to use the exact version of the add-on listed in the STR.

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

This won't get fixed in 78.

When you say, "Note that current versions of some add-ons have workarounds, do you mean 91? And it's a workaround, not a fix?

status-thunderbird_esr78: affected → wontfix
Flags: needinfo?(public)
Whiteboard: [datalossy]

(In reply to Wayne Mery (:wsmwk) from comment #20)

When you say, "Note that current versions of some add-ons have workarounds, do you mean 91? And it's a workaround, not a fix?

No, this is not about the TB version, but the add-on's version. For example, add-ons using the latest calendar API draft use this workaround: https://github.com/thundernest/tb-web-ext-experiments/commit/1b490daf9c4a27c7bc52c3d429f8c60dc2b1a851
In the case of Birthday Calendar this workaround was added in version 0.3, that's why I linked 0.2 in the STR.

The workaround prevents the calendar from unregistering at shutdown (which is wrong, but relatively safe as TB is closing anyway). That fixes the most pressing issue (calendar becoming disabled on each restart), but not all aspects of this bug. For example, disabled calendars will still be enabled when updating the add-on.

Flags: needinfo?(public)

Dirk, do you still see this?

Status: REOPENED → NEW
Flags: needinfo?(public)

You can still see add-on calendars that were invisible becoming visible on restarts or add-on updates (that properly reproduces, but is the the opposite direction form the original STR), but I am no longer able to reproduce the original STR. Note that the original STR is also no longer as relevant, as all add-ons include a workaround (but I cannot reproduce it even when patching out the workaround, unsure if it is just a timing thing).

This STR reproduces for me:
0. Thunderbird 102.10.0, clean profile

  1. Install the birthday calendar add-on from https://github.com/rsjtdrjgfuzkfg/thunderbird-birthdaycalendar/releases/download/v1.1/birthdaycalendar.xpi
  2. Observe that two calendars were created (for the default address books), which are visible
  3. Hide one of the two calendars observed in step 2
  4. Quit Thunderbird by closing the main window
  5. Start Thunderbird again and look in the calendar tab
  6. Hide the calendar observed in step 2, which was not hidden in step 3
  7. Update the add-on (just reinstall the same thing) and look in the calendar tab

Expected:
In steps 5 one calendar is hidden, in step 7 two calendars are hidden.

Actual:
In steps 5 and 7, both calendars are visible.

I'll update the description.

Flags: needinfo?(public)
You need to log in before you can comment on or make changes to this bug.