267688 - Can't use Save Search as Folder when it's already selected

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[David Feldman]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2

When the Save Search as Folder item is selected in the dropdown, it can't be
re-selected to bring up the corresponding dialog box.

Reproducible: Always
Steps to Reproduce:
1. Select Save Search as Folder
2. In the dialog box, click Cancel.
3. Try to re-select it.

Actual Results:  
Nothing.

Expected Results:  
The dialog box should re-open.

Comment 1

[Jean-Marc Desperrier]

The reproduction steps are a bit imprecise. Seamonkey mail has exactly the same
problem (in bug 271792), but it got mixed with bug 303895, so it looks a bit
different.

Here are better reproduction steps, base on bug 271792 :
1.MailNews->Threadpane-filter 'View:' choose 'Save Search as a Folder...'
2.The 'New Saved Search Folders' dialog appears.
3.The selected entry in the drop-down list stays what is used to be
3.Click 'Cancel' or use the upper right close button to close the dialog.
4.Choose 'Save Search as a Folder...' again.
5.No dialog is opened!
6.'Save Search as a Folder...' now appears as the selected entry in the
drop-down list!
7.Choose 'All' and everything is well again.
8.Start the game again at [1.]

Expected Results:  
'New Saved Search Folders' dialog should appear every time
'Save Search as a Folder...' should never be the selected entry in the drop-down
list.

The funny thing is that the "Customize..." entry in the list as the same kind of
behaviour (an unselectable entry in the list that open a dialog instead of being
selected), but there is no bug in it.

As Seamonkey mail has exactly the same problem, I suspect a patch for this
should be be very easily ported to seamonkey and it would be nice to check in a
correction for the two together.

I checked this only in trunk, don't know if 1.0.x has it too. But even if it
fails there too, I'm not sure it's worth being backported.

Comment 2

[Jean-Marc Desperrier]

I'll add a reference here to the parts of the comment below that apply to the TB
version of the bug too.
https://bugzilla.mozilla.org/show_bug.cgi?id=303895#c4

> One thing that I noticed with both patches is that if you custom after save,
> then the menuitem gets set to save instead of the original view.

We need to add that to the description and close only when this part is solved too.

>+<!ENTITY viewPickerSaveAsVirtualFolder.label "Save Search as a Folder...">
>I think this should say "Save View as Folder..." as it doesn't save the Quick
>Search, right?

Indeed "Save Search as a Folder..." uses the currently selected view as a base
for what will appear in the virtual folder, and *not* the results of the last
Quick Search. Changing the name is easy, but maybe it's more that the
functionnality was implemented wrongly ? Because if you created a view that does
something, it's not so useful to have a virtual folder that does the same,
whereas using a quick search as the base for a virtual folder makes more sense.

Comment 3

[Ian Neal]

Hopefully this has now been fixed by the patch for bug 303895 that has been
checked in.

Comment 4

[Wayne Mery (:wsmwk)]

WFM version 3.0a1pre (2007112004)