Closed RealRaven2000 closed 2 years ago
I had a brief call with @jobisoft, he suggested to find all custom elements and replace them with themselves after patching:
https://developer.mozilla.org/en-US/docs/Web/API/Element/replaceWith
This should trigger the correct, patched versions for the UI.
Question: will this also instanciate the correct event listeners?
Hi, probably you're interested in the following discussion on topicbox: https://thunderbird.topicbox.com/groups/addons/Ta7dc4ea69d14e2a4/onloadwindow-fires-too-late
Regards, Günter
Screenshot of a test filter:
Here is a filter you can load with quickFilters "restore filters" button: patch test.zip
To load the patch file, install quickFilters: quickFilters-wx-5.5.2pre36.zip
... then open Message Filters and use the Yellow "Restore filters.." button on the tololbar to import the filter:
To reproduce the problem in Thunderbird 102 beta1, use: filtaquilla-3.5pre6.zip
Related bug on Thunderbird's bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1772376
To test the missing custom terms with FiltaQuilla they need to be enabled in FQ options:
Hi, probably you're interested in the following discussion on topicbox: https://thunderbird.topicbox.com/groups/addons/Ta7dc4ea69d14e2a4/onloadwindow-fires-too-late
I had seen this, don't quite understand how you made it work. I came up with a wrokaround for the search terms (re-adding the elements and populating them from the search terms) - but sadly that wont work for the actions as they have no editable elements that can be re-added:
let terms = document.getElementById("searchTermList");
for (let i=0; i<terms.itemChildren.length; i++) {
let el = terms.itemChildren[i];
if (gFilter.searchTerms[i].attrib == -2) {
if (gFilter.searchTerms[i].customId && gFilter.searchTerms[i].customId.startsWith("filtaquilla")) {
// this is one of my own search terms...
let val = el.querySelector("search-value");
let filterVal;
try {
// evalute the nsIMsgSearchValue
filterVal = gFilter.searchTerms[i].value.str;
}
catch(ex) {
}
if (filterVal && val && val.getAttribute("value") != filterVal) {
console.log(`Fixing search term ${gFilter.searchTerms[i].customId} - re-adding value "${filterVal}" ...` );
val.setAttribute("value", filterVal);
el.replaceWith(el);
}
}
}
console.log(el);
}
The workaround i'm using only works for the filterAction case. I can't say anything about the searchTerm case.
I found, that the function isValidForType() from the filterAction is always called before _getChildNode() is called. So i did a check in isValidForType if _getChildNode is already patched (which is the case up to TB100). If it is not already patched, i do it now. That seems to work, no need to deal with the DOM.
The workaround i'm using only works for the filterAction case. I can't say anything about the searchTerm case.
I found, that the function isValidForType() from the filterAction is always called before _getChildNode() is called. So i did a check in isValidForType if _getChildNode is already patched (which is the case up to TB100). If it is not already patched, i do it now. That seems to work, no need to deal with the DOM.
Without code it still is hard to understand - do you have a diff you can point to? Do you add any custom edit fields in the action row? My understanding is that isValidForType may be called by the message filter dialog when it loads, but it does not help as long as none of my patch code has been called? what event / core function calls the function isValidForType()
in your case?
isValidForType() is part of the filterAction object which you have to feed into MailServices.filters.addCustomAction(filterAction); See your file filtaquilla.js e.g. line 186.
Here is a fixed version - we managed to write a script loader module that loads the patch script earlier (on the DOMContentLoaded
event):
To install download zip file and drag into Thunderbird Add-ons Manager (don't unpack)
To do:
Latest fix for bad coloring in dark themes:
To install download zip file and drag into Thunderbird Add-ons Manager (don't unpack)
Fixed in 3.5 - released on 13/07/2022
@RealRaven2000 I just encountered this issue in TB 102.8.0 even with filtaquilla 3.7. Is this a regression bug?
I don't know can you load the previous version and see if it works there please?
Where do you get From (RegEx)
from?? that does not seem to be part of standard FiltaQuilla. All other fields work for me (Thunderbird 102.9, should also work in the previous version):
I had 3.6.1 installed before with the same issue. I haven't used the regex filters before. I just wanted to use them for the first time.
I still don't know how you get From(Regex) - are you sure these are provided by FiltaQuilla? These are the ones you can enabled from FiltaQuilla settings:
It looks like this: The labels "Header (Regex)" "From (Regex)" and "Subject (RegEx)" from your screenshot are not added by FiltaQuilla. Do you have another Add-on installed such as search tools NG or quick Search NG?
I will check that and report back. thanks for the hint!
@RealRaven2000 you were right, expression search NG was the culprit. Unfortunately you cannot see which addon contributed which filter in TB. So I ended up here. Thanks again for your responses.
This is obviously a regression caused by changes in Thunderbird Core. It is caused by code injected via
is not loaded in time so the appropriate functions don't get monkey-patched before the editor is filled with actions / search conditions.
The code works as expected when manually adding a filtaquilla specific search term or action, but the filter editor is incapable / fails to add these correctly from a saved filter, making once generated filters impossible to edit.