Following on from bug 493700, there are some functions that are message related but don't pass through the default controller code. Hence when we visit a non-message window type tab (e.g. What's new or about:rights), these functions are enabled when they don't apply. The following are the ones I've found so far: - File -> Attachments - File -> Subscribe (though this seems to be enabled for local folders as well, which is also probably a bug). - Edit -> Favourite Folder - View -> Layout - View -> Folders - View -> Sort By - View -> Threads - View -> Headers - View -> Message Body As - View -> Display Attachments Inline - View -> Message Security Info - Message -> Move To (and again?) - Message -> Copy To - Message -> Tag I'm not sure if we should disable all the ones in the View menu I've suggested, maybe Bryan can provide input here.

I'm not sure any of those would make sense in an alternate tab type so I can't see keeping them enabled. Any item of those items wouldn't be able to give the right kind of feedback (layout changes, message is moved) that they did something. Are those items going to continue to affect the other tabs or just not work?

(In reply to comment #1) > I'm not sure any of those would make sense in an alternate tab type so I can't > see keeping them enabled. Any item of those items wouldn't be able to give the > right kind of feedback (layout changes, message is moved) that they did > something. Are those items going to continue to affect the other tabs or just > not work? The intention is that the items would be disabled, but if (for instance) someone created their own message view tab type and the functions were relevant, then they could be enabled. At least passing them through the DefaultController would allow them to be disabled in other tabs. For anyone wishing to work on this bug: The menu options for TB are defined in mailWindowOverlay.xul. Some of these go through command elements, some do not. The ones that do not and that are listed in comment 0, need to be turned into commands and linked into the commandsets at the top of mailWindowOverlay.xul. Then, in mail3PaneWindowCommands.js there is the DefaultController which needs to handle the commands, and they also need handling in messageWindow.js/MessageWindowController. Bug 495818 attachment 381253 [details] [diff] [review] has an example where we've done this sort of transition for cmd_fullZoomEnlarge and other zoom functions.

Bug 67219 is improving the message filters menu option and including it in the default controller code. Adding dep.

I'm close to finishing a patch that fixes this.

I'm a bit puzzled... I've gone though the mailWindowOverlay.xul and added in the missing command elements associated with the incorrectly enabled menu-items. Sadly the changes in the script don't seem to have any effect on the incorrectly enabled menu-items. There is a comment in the code that mentions a utilityOverlay.xul. I'm gathering that it is being used as a temporary bug fix. Does anyone know if the utilityOverlay.xul file overides the mailWindowOverlay.xul.

I don't know, but what happens if you change utilityOverlay.xul? Later, Blake.

Re: What happens if you change utilityOverlay.xul? It doesn't seem to apply here. I'm thinking the problem is related to how I'm building. I'm looking into that now. Lindauson

Could you elaborate on the building issue? (In reply to Lindauson from comment #7) > Re: What happens if you change utilityOverlay.xul? > > It doesn't seem to apply here. I'm thinking the problem is related to how > I'm building. I'm looking into that now. > > Lindauson

Well, it's been a long time, and frankly I don't remember as much as I would like to. From what I remember, the difficulty was in identifying why the changes to the .xul weren't being realized in my Thunderbird build. For instance, changes made to the utilityOverlay.xul didn't always register in the menus; so, I was a bit uncertain if it was an issue of me editing the wrong file, or a building error. Hope that helps. Lindauson (In reply to Shriram ( irc: Mavericks ) from comment #8) > Could you elaborate on the building issue? > > (In reply to Lindauson from comment #7) > > Re: What happens if you change utilityOverlay.xul? > > > > It doesn't seem to apply here. I'm thinking the problem is related to how > > I'm building. I'm looking into that now. > > > > Lindauson

mail3PaneWindowCommands.js and messageWindow.js/messageController in comment 2. Do they need to be dealt with for the script to work successfully?

(In reply to Shriram ( irc: Mavericks ) from comment #10) > mail3PaneWindowCommands.js and messageWindow.js/messageController in comment > 2. Do they need to be dealt with for the script to work successfully? You can also ask in #maildev on irc://irc.mozilla.org .

Lindauson indicates no draft patch is available