Closed Bug 519192 Opened 13 years ago Closed 13 years ago

Fix up context menu for gloda search results list tab - can't move, copy, tag, mark messages etc


(Thunderbird :: Search, defect)

Not set


(Not tracked)

Thunderbird 3.0rc1


(Reporter: standard8, Assigned: standard8)



(Whiteboard: [no l10n impact])


(1 file)

Spun off from bug 515770:

(In reply to comment #5)
> "Open as list" does the trick for search lists, but does not provide the
> following right-click actions:
> - Move message to
> - Copy message to
> - Move again to <last move made>
> - Delete
> - Label (and submenu)
> - Mark (and submenu)

This is an error in (after the part 1 patch on bug 519041) nsContextMenu.js - it assumes that we have a folder available to check if we can move messages or not.

I'm not sure of the exact solution for this yet but I'll take it on soon after bug 519041.

As this is all sharing the "mailContext" menu, it doesn't affect strings.
Flags: blocking-thunderbird3+
Whiteboard: [no l10n impact]
Whiteboard: [no l10n impact] → [no l10n impact][needs patch]
Attached patch The fixSplinter Review
This provides the capabilities to move/copy/mark/tag/create filter from messages in the global view as list view using the main message menu or the context menu.


- Added a new function to FolderDisplayWidget called canDeleteSelectedMessages; this lets us determine if we can delete messages in a folder (i.e. typically non-news) and can be used from more than one place.

- create from filter options adjusted to use the folder/server info from the selected message header rather than the displayed folder (as gloda view as list doesn't have a folder).

- Main message menu and context menu items similarly adjusted to look at the details of the folders etc on the selected message headers rather than the display folder.

- I used MessageDisplayWidget.isDummy in a couple of places to detect an .eml file loaded in a standalone message window.

- One hack applied for moving messages (the do copy rather than move option comes into play for the "File" toolbar button); the current detection is for if the folder URI is a news URI. This is actually incorrect for saved searches (which could be cross non-news and news), but also gloda view as list doesn't have a folder hence no URI. As gloda doesn't currently index newsgroup messages, I've based the current determination on whether or not the folder exists and then if its a news URI.

Tested context & message menus in standalone message window, tabs, 3-pane message, global view as list view and they seem to be working fine now.
Attachment #408232 - Flags: review?(bienvenu)
Whiteboard: [no l10n impact][needs patch] → [no l10n impact][needs review bienvenu]
Comment on attachment 408232 [details] [diff] [review]
The fix

I had some problems with messages where the server was using the imap delete model, but I suspect those problems also exist without this patch. The core view code is assuming a standard imap delete model across the whole view, which isn't true for gloda search results (or cross-folder search results in general)
Attachment #408232 - Flags: review?(bienvenu) → review+
Checked in:
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [no l10n impact][needs review bienvenu] → [no l10n impact]
You need to log in before you can comment on or make changes to this bug.