Open
Bug 495815
Opened 16 years ago
Updated 2 years ago
Not all message related functions go through the default controller code (tabs, disable menu items)
Categories
(Thunderbird :: Toolbars and Tabs, defect)
Thunderbird
Toolbars and Tabs
Tracking
(Not tracked)
NEW
People
(Reporter: standard8, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: student-project, Whiteboard: ucosp)
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.
Flags: wanted-thunderbird3+
Comment 1•16 years ago
|
||
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?
Reporter | ||
Comment 2•16 years ago
|
||
(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.
Keywords: student-project
Reporter | ||
Comment 3•15 years ago
|
||
Bug 67219 is improving the message filters menu option and including it in the default controller code. Adding dep.
Depends on: 67219
Summary: Not all message related functions go through the default controller code → Not all message related functions go through the default controller code (tabs, disable menu items)
Updated•15 years ago
|
Assignee: nobody → lindauson.hazell
Status: NEW → ASSIGNED
Whiteboard: ucosp
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.
Comment 6•15 years ago
|
||
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
Comment 8•13 years ago
|
||
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
Comment 10•13 years ago
|
||
mail3PaneWindowCommands.js and messageWindow.js/messageController in comment 2. Do they need to be dealt with for the script to work successfully?
Comment 11•13 years ago
|
||
(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 .
Comment 12•10 years ago
|
||
Lindauson indicates no draft patch is available
Assignee: lindauson.hazell → nobody
Status: ASSIGNED → NEW
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•