Closed Bug 1492386 Opened 6 years ago Closed 5 years ago

Filter settings, drop-down list blank, caused by thousands of tags defined from RSS feeds

Categories

(Thunderbird :: Filters, defect)

52 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1342054

People

(Reporter: user987643, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Steps to reproduce:

extras -> filters -> new... -> "Filter bearbeiten" (edit filter) window.
Then I click on one of the upper drop-down lists in the "Bedingungen" (conditions) box or I click on one of the lower drop-down lists in the "Auszuführende Aktion" (action to be performed) box.


Actual results:

upper drop-down list: No list opens, just a tiny blue bar shows up under the now blueish list button.

lower drop-down list: the list options show up, but when I select one it is not set.


Expected results:

I should in both cases be able to see the options and to select one of them.
Something corrupt in your installation. Also, TB 52 is nearly no longer supported. Try TB 60.
Thank you for your answer.

I have updated to 60.3.2 and the bug persists.
But it has changed since I reported it. Currently I see text in the dropdown boxes, but If add another box by clicking on the "+" box I get the following error message:
"Ein Skript auf dieser Seite ist eventuell beschäftigt oder es antwortet nicht mehr. Sie können das Skript jetzt stoppen oder fortsetzen, um zu sehen, ob das Skript fertig wird.

Skript: chrome://messenger/content/mailWidgets.xml:2117
"
My own translation of the german text: "The script is busy or does not respond. You can stop it or continue it to see whether it will finish."
The whole software is very slow and does not respond until the error message appears. It takes less than a minute for each error message to appear.
If I click on "proceed" for a couple of times it sometimes finishes the task and I can set up the filter.
We haven't had other reports of this. So you can try two things: 1) Restart without add-ons, see Help menu. 2) Create a new profile, start thunderbird.exe -p to create one, and try it there. Using TB 60, I can add filter conditions and actions using the [+] buttons.

Do you have filters with many rules? How big are your msgFilterRules.dat files? Can you rename/move one and see what happens. You'll find them in your profile which you can open via |Help > Troubleshooting Information|.
Aceman, ever seen something like this?
Flags: needinfo?(acelists)
Is there anything interesting in Tools->Developer tools->Error console AFTER you see this?

If you see this in TB60.3, then the line chrome://messenger/content/mailWidgets.xml:2117 points to https://dxr.mozilla.org/comm-esr60/source/mail/base/content/mailWidgets.xml#2117 .

May you have a very long list of message tags? See Tools->Options->Display-Tags .
Flags: needinfo?(acelists)
(In reply to Jorg K (GMT+1) from comment #3)
> We haven't had other reports of this. So you can try two things:
> 1) Restart without add-ons, see Help menu.
No difference.

> 2) Create a new profile, start
> thunderbird.exe -p to create one, and try it there. Using TB 60, I can add
> filter conditions and actions using the [+] buttons.
I did use -ProfileManager. I think that this works too.
So I have created a new profile.
In this new profile the filter settings work fine and fast.

But what should I do now? My default profile is quite large and not so easy to redo.
Is this the end of the story?


Just for the sake of completeness:
> Do you have filters with many rules? How big are your msgFilterRules.dat files?
I do not use many filters or rules. 5KB.

> Can you rename/move one and see what happens. You'll find them in
> your profile which you can open via |Help > Troubleshooting Information|.
When I rename it, after a restart thunderbird creates a new file. It behaves in the same buggy way, when I create a filter.

(In reply to :aceman from comment #5)
> Is there anything interesting in Tools->Developer tools->Error console AFTER
> you see this?
yes

NS_ERROR_NOT_AVAILABLE: Cannot call openModalWindow on a hidden window nsPrompter.js:340
TypeError: menupopup.selectFolder is not a function[Weitere Informationen]  searchWidgets.xml:723:35

"Weitere Informationen" means "more information" or "additional information".
When I click on it (as it appears to be a link) the following line appears:
TypeError: this.chromeUtilsWindow.openUILinkIn is not a function[Weitere Informationen] hudservice.js:387:7

All those lines appear before the error message shows up, but after the window opens up in which you set up the filter rules. At that time the software is already slow.

> If you see this in TB60.3, then the line
> chrome://messenger/content/mailWidgets.xml:2117 points to
> https://dxr.mozilla.org/comm-esr60/source/mail/base/content/mailWidgets.
> xml#2117 .
> 
> May you have a very long list of message tags? See
> Tools->Options->Display-Tags 
There are 41 thousand lines beginning with " user_pref("mailnews.tags. " in my prefs.js
I think that are around 20 thousand tags because each entry exists as both a ".tag" and a ".ordinal" entry.
In the menu there are a lot of message tags (display-tags). I am not sure whether those are more than a few hundred, but I cannot count them in the settings menu.

I hope my explanations are comprehensible. Thank you so far.
Hmm, I have definitions for five tags, that's 10 lines, plus three more entries, 13 in total.

How about to delete all the "couple lines" (after making a backup) and only leave:
user_pref("mailnews.tags.$label1.color", "#FF0000");
user_pref("mailnews.tags.$label1.tag", "Important");
user_pref("mailnews.tags.$label2.color", "#FF9900");
user_pref("mailnews.tags.$label2.tag", "Work");
user_pref("mailnews.tags.$label3.color", "#009900");
user_pref("mailnews.tags.$label3.tag", "Personal");
user_pref("mailnews.tags.$label4.color", "#3333FF");
user_pref("mailnews.tags.$label4.tag", "To Do");
user_pref("mailnews.tags.$label5.color", "#993399");
user_pref("mailnews.tags.$label5.tag", "Later");
user_pref("mailnews.tags.version", 2);
(In reply to user987643 from comment #6)
> > May you have a very long list of message tags? See
> > Tools->Options->Display-Tags 
> There are 41 thousand lines beginning with " user_pref("mailnews.tags. " in
> my prefs.js
> I think that are around 20 thousand tags because each entry exists as both a
> ".tag" and a ".ordinal" entry.
> In the menu there are a lot of message tags (display-tags). I am not sure
> whether those are more than a few hundred, but I cannot count them in the
> settings menu.

As Jorg said, there are 5 default tags shipped with TB, that amount to 10 pref lines.
So if you have thousands, that may contribute to the slowness as all those tags have to be put into a menu that you can choose from in the filter editor.

Can we assume you didn't create all the thousands of tags manually? Maybe an extension/addon did?
Do they seem auto-generated? Do you use any addon, that e.g. colors messages based on some criteria? That one could use tags to achieve colors.
If you do not recognize any of the tags and do not have such an addon, you could remove all those except the default tags.
You say in a new profile the speed is fine, but in the old profile the filter editor is still slow even with no filters. Tags are stored in prefs and clear filters has no effect on the assumed problem here.
Maybe they come from the RSS Feeds. There is a setting in Feed Subscriptions: Automatically create tags from feed <category> names.
> Can we assume you didn't create all the thousands of tags manually? Maybe an
> extension/addon did?
> Do they seem auto-generated? Do you use any addon, that e.g. colors messages
> based on some criteria? That one could use tags to achieve colors.
> If you do not recognize any of the tags and do not have such an addon, you
> could remove all those except the default tags.
They were automatically generated from RSS categories. There is a setting for this in the account settings.
Actually I did not really need the tags, but I did not reckon that they would cause trouble.
Of course I unchecked this option just now.

I have deleted the " user_pref("mailnews.tags. " entries and it makes a big difference.
Thunderbird starts faster than usual and the filter settings are smooth and fast.

Therefore the issue is solved. :-)
I thank you for your patience and help.

edit:
yes Richard Martl, that is exactly right. :-)
Maybe one day we can address the underlying issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Filter settings, drop-down list blank → Filter settings, drop-down list blank, caused by thousands of tags defined from RSS feeds
But how? What are those 'categories' in feeds?
Could the user encounter 20000 of unique ones so that so many tags got generated?
Flags: needinfo?(alta88)
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(alta88)
Resolution: --- → DUPLICATE
Well, we could load the tags only if they are really needed in the filter editor.
I could do that.

Bug 1342054 seems to be about the preferences UI (where of course we have to load the tags), but also about general slowness of the UI when many tags are present. But that would need more proof/investigation if that is the case.
Well, if you read that bug, you'll see it was about all places where very large numbers of tags affected perf. And Bug 996690 already had a patch to handle those places (skip AUTOTAG tags) but it was desired to leave that part out. Another way, rather than skipping AUTOTAG tags when building a menulist, is to just have a setTimeout on the menulist build functions so the filter etc dialogs open first. Once a menulist with 10s of thousands of items is built, it may be a pain and useless to scroll, but the popup won't take long unless it clears and rebuilds its items onpopupshowing().

And what does 'really needed' mean anyway, codewise?
'really need' in the filter editor is when the user opens the menulist with tags. Which is not when a filter is just opened.

But currently it seems all elements are built beforehand and then switched by a <deck>. But we could populate the tag menulist only on 'onpopupshowing' event.
Of course, not showing the automatically generated labels in the UI may also be a better solution if the user is never intended to use them manually.
right, but if you do it onpopupshowing it will take a long time and hang the ui. it needs to be done in the background, after the window has opened, and the user is just looking at it.  ie on setTimeout and even then maybe with async methods (but that would be a bit of renovation perhaps). otherwise, you can't even start a throbber or such with feedback to wait.

just use the bits in the .xml files here:
https://bugzilla.mozilla.org/attachment.cgi?id=8407017
oh, and searchWidgets.xml does it in the constructor, really bad design.  you might tweak that on general principal.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: