Closed Bug 840591 Opened 7 years ago Closed 7 years ago

regression: The "Copy To" and "Move To" context menus do not list any sub-items


(MailNews Core :: Backend, defect, major)

Not set


(Not tracked)

Thunderbird 21.0


(Reporter: klonos, Assigned: aceman)



(Keywords: regression)


(4 files, 1 obsolete file)

This started to happen 2 or 3 nightly updates back but used to work just fine a few days ago:

When right-clicking on any message from the message list pane, the "Copy To" and "Move To" menu entries of the context menu do not work. There is only an empty menu "artifact" instead of the normal sub-menu items. Please see attached screenshot.
...forgot to say that this is the default theme being used and only a minimum of extensions. The same happens to a test x64 latest nightly build with no extensions installed. Didn't try x86 builds though.
Seems to work fine here with a 32 bit build Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Thunderbird/21.0a1 20130212031206
Please try in TB safe mode (help->Restart with addons disabled) first. If the problem persists, see in Tools->Error console if there are any errors AFTER you try to invoke the submenu.
This menu is used in more places (e.g. in filter editor (target of move message to), or folder->New subfolder). Does it work fine at those places?
Here's what I've tried so far:

1. I've backed up my profile and disabled all addons manually from the Addons Manager.
2. I've restarted from the Help -> Restart with addons disabled just to be sure.
3. I've also enabled the "Reset toolbars and controls" option from the Safe Mode dialog.
4. Installed the latest x86 nightly and loaded the same profile.
5. Repeated steps 1 through 3 with the x86 build.

I see only these 2 messages (no warnings - no errors) in my error console, but before I even invoke the context menu:

Could not read chrome manifest 'file:///C:/Program%20Files/Mozilla/Thunderbird/chrome.manifest'.

Could not read chrome manifest 'file:///C:/Program%20Files/Mozilla/Thunderbird/extensions/%7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D/chrome.manifest'.

The same behavior and messages in the error console in both x64 and x86.

Any additional steps to further troubleshoot this?
Can you try an older nightly to find out when it started? There were changes that could affect this sub-menu recently so there are suspected bugs, but we do not see the problem on our machines.

Btw, are you able to build Thunderbird from source?
The "Move Message to" and "Copy Message to" actions in the filter rules dialog do NOT work.

The "Create as a subfolder of" drop-down selection in the New Folder dialog works fine though.

I'll try going one nightly back at a time to see which build caused the regression and I'll report back.
OK, so it seems that the menus that have the "Recent" group do not work. That was recently changed in bug 809066, checked in on 2013-01-31.

When going back with nightlies, beware of bug 807848, you'll need to reset the preference (to true).
Thanx mate for the heads-up, wasn't aware about that and I was about to file it as a new bug. So, I tried only x64 nightlies so far:

- 2013-01-28-03-10-22-comm-central is the last where the context menu works right
- 2013-02-08-03-05-01-comm-central is where the regression occurs

I know the gap of builds is greater when it comes to x64 (no x64 builds from Jan 29 to Feb 8), so I'll try to narrow it further down by testing things with x86 builds too. Let me just do that and I'll report back...
...ok, as far as x86 go:

- 2013-01-31-03-10-51-comm-central is the last where the context menu works right
- 2013-02-01-03-10-03-comm-central is where the regression occurs

Hope this helps to figure things out. Let me know if you need anything else.

PS: To answer the question back in comment 5 about building tb from source: I've never done it, but I guess I might be able to.
Thanks, so that looks like bug 809066 may be the culprit, but I do not see what is wrong, as there is no error in the console.

The change in that bug is pure javascript, so you can get away even without building from source. Just download the file here: . Then open the omni.ja file in your TB installation and replace this file in the archive.
Yep, confirming that replacing the folderWidgets.xml file under \omni.ja\chrome\messenger\content\messenger\ fixes the issue with the latest x64 nightly.

Thanx @:aceman !!! ;)
OK, so that was a version of folderWidgets.xml without the patch in bug 809066. Now only to find out what is going wrong in your installation, as we do not see the problem on our systems. The menu comes up fine.

Could you please attach a screenshot of the submenu when it is working correctly? Maybe you have some exotic folder names that we didn't expect.

Then, use the original version of the file (the not working one from a recent nightly), find this block in the file:
<method name="_build">
<parameter name="aFolders"/>

Directly after this line, insert a line saying:
try {

Then find the end of the function like this:
//xxx for later optimization

There, before the "}" insert this line:
} catch (e) { Components.utils.reportError(e); }

Save the file, put into the archive, run TB and use the submenu, see the error console.
On the screenshot please also try to expand the "Recent" submenu.
Attached image working context menu
Here's a screenshot of the working context menu.

As far as non-standard alphanumeric characters in the folder names go, I have '@', '&', '.', '-' and spaces. These are the ones included in the "Recent" submenu, but I have also folders with '[', ']', ''', '(' and ')' not included in the "Recent" submenu. Out of these, the only one I guess might not be escaped correctly and perhaps causing issues would be '&', but I honestly could not know for sure.

Give me some more time to apply the other changes you request and see what the error log spits. I'll report back soon as I have results...
Is that icon on Recent in the base install of TB for Win7? I do not get any icon on Win XP. Or does some of your extensions/themes add it?
...alright, I've made the changes to the folderWidgets.xml, updated the omni.ja archive and launched tb in order to test. I've cleared the error log and invoked the context menu. No message/warning/error in the console whatsoever :/

What can I do next?

PS: I'm attaching an archive to help others with troubleshooting. It includes:

- the original/untouched folderWidgets.xml file included in the omni.ja file of the latest x64 nightly
- folderWidgets.xml-nobug809066 [the version you link to back in comment 10]
- folderWidgets.xml-try-catch [the original version with the try/catch code from comment 12 included]
Assuming you did those tests in TB safe mode I have no ideas currently. Does your account name have any special characters?
Also please answer comment 15.
The icon is from the Toolbar Buttons addon plus that screenshot is with the Phoenity theme enabled (I enabled all addons once I replaced the folderWidgets.xml with the one previous to the bug, since I once again had a working setup). But the issue occurs with all addons disabled in safe mode as well once I replace the folderWidgets.xml with either the original or the try/catch one.

As for the account... actually this is a multi-account profile (about a dozen different accounts from various domains). I use global Inbox/Drafts/Sent/Junk for all accounts and then filter mail into a multitude of folders and subfolders. There are no special characters in the email addresses for these accounts. They are all in a username@domain.ext format where neither the username or domain part contain chars like '-' or '_'. They actually don't even contain numbers - only Latin alphabet letters and no punctuation at all. For example: NOT:
The way the new account wizard works now leaves me with no way to troubleshoot this issue by creating a new profile. I mean, what steps should I follow in order to create a new profile (so we can exclude any addon interference and any misconfiguration), but at the same time keep my mail (folder structure) intact and all my mail accounts in place too?
In your new profile, cancel the wizard, and create an RSS account? (Plus of course subscribing to a feed will give you some messages you can use for test purposes!)
You can start TB with the -P command line parameter.
I already use the -P parameter in my tb shortcut because I have a few profiles (mostly for debugging).

I used the RSS feed account trick in a brand new profile and the bug does not occur there.

Let me try another thing...
Ok, here's what I've done so far:

1. Backed up my current profile.
2. Blocked tb from accessing the internet (so that no new mail is sent/received).
3. Created a new profile.
4. Copied my Mail folder from the old profile to the new one.
5. Copied all the following user_pref entries from prefs.js:


These steps allowed me to have a working copy of my old folder structure. So far, the context menu seems to work fine, so I doubt it was a filename issue.

What I plan to do next is get my filters copied and working before I allow firewall access to tb once again (so that I don't get a tone of email and then have to manually archive it to the proper folders).

So, before I slowly recreate my old profile from scratch (installing addons, setting tb configuration to my liking etc), would you like me to take any further actions to help you to locate the cause of this issue? Or should we dump it as a misconfiguration/upgrade thing and leave it there? Let me know.
Keep the old profile backed up so that you can compare prefs.js file from the old and new profile. Maybe you'll spot something interesting.
Duplicate of this bug: 842036
windbg (not error console) shows 
[JavaScript Error: "TypeError: a.getStringProperty is not a function" {file: "chrome://messenger/content/folderWidgets.xml" line: 513}]
Thanks to Wayne for debugging this. The error in his report shows the culprit code. 'a' really is not a nsIMsgFolder due to mistake in bug 809066.
This does affect all of c-c but is only seen if there are more than 15 Recent folders.
Blocks: 809066
Component: Folder and Message Lists → Backend
OS: Windows 7 → All
Product: Thunderbird → MailNews Core
Hardware: x86_64 → All
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → acelists
Attachment #714806 - Flags: review?(neil)
Comment on attachment 714806 [details] [diff] [review]

(I wonder whether it's worth caching the prettyMame or MRMTime in the object too.]
Attachment #714806 - Flags: review?(neil) → review+
(In reply to comment #30)
> (I wonder whether it's worth caching the prettyMame or MRMTime in the object too.]
Bah, it's not even late and I'm making typos all over :-(
Attached patch patch v2Splinter Review
Good idea Neil.
Attachment #714806 - Attachment is obsolete: true
Attachment #714831 - Flags: review?(neil)
Attachment #714831 - Flags: review?(neil) → review+
Keywords: checkin-needed
Closed: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 21.0
Thank you people!!!

This change unfortunately did not make it into the latest x64 nightly (2013-02-16-03-05-50-comm-central). Oh, well I'll wait till the next build then. Thanx once again ;)
There is not even a 32bit build with the fix yet. But surely will be in next hours.
Thanks for the report!
You need to log in before you can comment on or make changes to this bug.