Filter assistant not using correct built in template (domain instead from)

[PotatoCarl]

Hi
When I use the filter assistant with 6.13pre85 and I select "filter by from mail address" it selects instead the DOMAIN of the sender (@...) only, not the full email address.

This just started to happen today, until then it worked fine.

[RealRaven2000]

Can you make a screenshot of the selected template (even it if is in German) - this one works for me:

[PotatoCarl]

Yes, that is that template (same you selected). It does not select the email address but only the domain as of the last version above.

[PotatoCarl]

Now it works again???? it did not work since friday, despite multiple restart of Thunderbird and reboots, but today it works again???
Totally confused

[RealRaven2000]

Now it works again???? it did not work since friday, despite multiple restart of Thunderbird and reboots, but today it works again??? Totally confused

Me too - but notice how the template (at least on my system) is "sandwitched" between 2 templates that deal with domains. So maybe somehow the wrong got selected, and maybe it is caused by the the update to the new version within the session, and may not have happened after a restart.

The selection uses the preferences to store the selected template

  setCurrentFilterTemplate: async function (pref) {
    return quickFilters.Preferences.setStringPref("filters.currentTemplate", pref);
  },

the default template is "from" (not the one using the Domain). Now we did have a migration from Legacy PReferences to local (browser) storage in this version, and I do a conversion from one to the other, which I had to refine, so I triggered this a number of time by increasing an internal version number in preferences.js:

export const Preferences = {
  CURRENT_VERSION: 1.61,
  Defaults: {

any time I increased that number I would force overwriting these by using the Legacy preferences => browser storage. Also for performance reasons I keep a cached version of these settings in 2 layers: the background page and the legacy (also called "experimental") code part - these 2 layers constantly communicate with each other which is especially tricky in the assistant as a lot of the logic runs on the experiment but the dialog uses API compatible code layer, and then communicates back via the background to the experimental layer what selections have been done by the user. But I am cheating here a little but simply storing these settings globally within browser.storage.

browser storage has a change listener which should update all other parts to overwrite their cached settings, so in theory everything should remain synchronized. I would have to explorer whether I would be able to select the default template "from" for a new (or merged) filter with the assistant and then whether changing to the "domain" template would not be communicated back to the legacy layer.

IN the preferences code change listener (which lives in the background) I am using an experimental API messenger.Utilities.updatePreferencesCache in order to tell the legacy code that new settings were requested:

    // live sync all changes to cache
    messenger.storage.onChanged.addListener((changes, area) => {
      try {
        console.log("Preferences onChanged:", changes);
        if (area !== "local") {
          return;
        }
        if (!changes.settings && !changes.debug) {
          return;
        }
        const updates = {};
        if (changes.settings) {
          applyChanges(Preferences._data, changes.settings, updates, Preferences.Defaults);
        }
        if (changes.debug) {
          applyChanges(Preferences._debugData, changes.debug, updates, Preferences.DebugDefaults);
        }
        if (!Object.keys(updates).length) {
          return;
        }

        console.log("Preferences updates:", updates);
        messenger.Utilities.updatePreferencesCache(updates);
      } catch (e) {
        console.error("storage.onChanged crashed:", e);
      }
    });

this calls a legacy code function "quickFilters.Preferences.cache.updateFromBackend" which lives in the last global window (where the filter worker lives, which does all the pre- and post-processing before the assistant window it called up via the background)

var win = Services.wm.getMostRecentWindow("mail:3pane");
...
...

        updatePreferencesCache: (data) => {
          return win.quickFilters.Preferences.cache.updateFromBackend(data);
        },

so one problem might be if you opened another 3pane window and then called the assistant from there, I am not sure whether all instances get these change updates. It gets very complicated in that case. I might just do an iterator across all 3pane window to make sure this change is broadcasted everywhere in legacy code land.

Sorry this is so complicated, in the long term I would like to have more of that logic in the background code or at least in mail extension compatible / API driven code: but there are currently no filter APIs, so I have to work with the Thunderbird core code directly. Converting the assistant from xhtml (old legacy way) to html while still working within the legacy logic was one of the most complicated pieces from the architecture POV, that's why it is also very hard to reproduce (or even reason through) a glitch like you reported here.

[RealRaven2000]

I made a little test by switching from the new (default) HTML assistant to the old one:

If I select a different template here (e.g. domain) I suspected it might not save it correctly, but both the old and the new assistant use the same place to store the last selected template, namely filters.currentTemplate in browser storage. The original setting in legacy prefs was extensions.quickfilters.filters.currentTemplate. Apparently I did the storage conversion correctly as it uses the new location in all code paths.

Apart from that I am planning to retire the old (xhtml) version of the assistant shortly. I only kept it in case there were catastrophic side effects for some users.

[RealRaven2000]

New version - I had to fix the way the preferences cache was read (fallout from changes in #367 leading to a regression that didn't read all settings in legacy code)

quickFilters-6.13.1pre21.zip

---

To install the version above, download the zip file and then drag the file into Thunderbird Add-ons Manager. Do not extract contents, it will not install that way. T