[UW-IMAP] Alerts display when search msgs from folder-only folder

VERIFIED FIXED

Status

SeaMonkey
MailNews: Message Display
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: BenB, Assigned: Navin Gupta)

Tracking

({imap-interop})

Trunk
imap-interop

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
Reproduction:
1. Search a folder hierarchy on an UW-IMAP server

Actual result:
2 error dialogs appear for each folder-only-folder that is included in the
search (equal or below the selected folder):
"... SELECT failed... not a selectable mailbox"
"failed ... UID FECTH"

Expected result:
Folder-only-folders are not searched (only their msg-onyl subfolders).

Additional Comments:
Relevant checkbox is activated. Folder-only-folders recognized in folder pane.
(Reporter)

Updated

17 years ago
Keywords: interop, mozilla1.0
QA Contact: esther → huang
Summary: [UW-IMAP] Searching folder hierarchy fails → [UW-IMAP] Searching folder hierarchy gives lots of errors

Comment 1

17 years ago
reassigning to naving
Assignee: gayatrib → naving
(Assignee)

Comment 2

17 years ago
This happens in 4x also. I think it is a UW:IMAP server problem because it 
should clean-up the folders that are no longer there. 
(Reporter)

Comment 3

17 years ago
Navin, are are misunderstanding this bug.

It does not happen with 4.x.

It is not about "folders that are no longer there", but about folders, that can
contain only other folders, but no messages, i.e. are not "selectable" and
cannot be searched. Nevertheless, they are subscribed and completely valid,
since they are my only way to get to other lower-level folders, which do contain
messages.
Technically, folder-only-folders are directories on the server file system,
while msg-only folders are mbox files. Both of them can be visibile ("subscribed").
So, the server does behave corrent. (Unless I'm missing something.)
(Assignee)

Comment 4

17 years ago
*** Bug 92151 has been marked as a duplicate of this bug. ***

Comment 5

17 years ago
Yes! This problem is not occurring on 4.77.
But, I can only reproduce this problem by uisng 08-02-06-trunk build:
It shouldn't display this alert when search the msgs under the UW folderonly 
folder since it's possible to create sub-msgonly folders under the folderonly 
folder. And users should allow to search those msgs under the folderonly folder 
if they don't know which sub-msgonly folders that those msgs reside....

Updating the summary a little bit to specify this problem....
Summary: [UW-IMAP] Searching folder hierarchy gives lots of errors → [UW-IMAP] Alerts display when search msgs from folder-only folder

Comment 6

17 years ago
Created attachment 44467 [details]
Attach the alert dialog screen shot when search msgs from the folder-only folders from UW account.

Comment 7

17 years ago
Actually after I select the OK from this alert.
The search functionality is working from the UW folder-only folder.
Just the alert shouldn't display, it will mislead users that it's not 
working......
(Reporter)

Comment 8

17 years ago
> Just the alert shouldn't display, it will mislead users that it's not 
> working......

It's not only misleading. Search a large hierarchy, and you easily get 20+
errors during a single search.

naving and I talked about this.

the two parts of the fix:

1) don't allow users to search "no-select" folders from the search picker.
2) when searching across an account, skip the no-select folders.
(Assignee)

Comment 10

17 years ago
I already have fix for the 2nd part in my tree. I will attach it soon. 
(Assignee)

Comment 11

17 years ago
For the first part we need to add that rule to the picker, right ?
right, we need to extend the picker to have disabled menuitems when the folder
is a no-select folder.

since it's UI, feel free to leave that to me if your overloaded with back end bugs.
(Reporter)

Comment 13

17 years ago
> don't allow users to search "no-select" folders from the search picker.

No, no no!

This is important functionality. E.g. I have a folder-only-folder for Mozilla,
which contains folders (and other folder-only folders, e.g. Beonex) to sort the
mails/bugmails after certain criteria. Sometimes, I remember a mail (about
Mozilla), but can't remember where I sorted it. So, I search in all Mozilla
folders. Searching the whole account is not an option, because that would search
through probably 100.000 mails in 400 folders. Searching msg-folders is no
option either, because I have about 50 folders under Mozilla.

When it works for whole accounts, why deliberately disable it for subhierarchies?

Illness healed, patient dead.

Comment 14

17 years ago
Yes. As I said:
>users should allow to search those msgs under the folderonly folder 
>when they don't know which sub-msgonly folders that those msgs reside....

I think my opinion is the same as Ben.....
(Assignee)

Comment 15

17 years ago
Created attachment 44608 [details] [diff] [review]
proposed fix
(Assignee)

Comment 16

17 years ago
This patch should fix the problem in an ideal scenario, but the noSelect flags 
are not set correctly for some folders at start-up, investigating that part 
of the problem. 
(Assignee)

Comment 17

17 years ago
Do we have another uw:imap server, the one I am using is sspitzer.mcom.com 
and I think it does not return a correct LSUB response, or may be server 
does not want to return any flag (NoSelect, NoInferior) (trying to optimize). 
benb is right, changing the UI is wrong.

thanks for catching my mistake.
(Reporter)

Comment 19

17 years ago
naving, are the folder-only-folders grey and italic for you in Mozilla? If so,
they should already be recognized as folder-only-folder (which is a synonym to
NoSelect folders, IIRC, not?).

If not so, then check the file ~/.mailboxlist (or yourroot/.mailboxlist?) on the
server (it's a textfile). Your folder-only-folders should have either no entry
there at all (only their subfolders - the folder-only-folder will then be
reported as subscribed automatically) or an entry with a trailing slash.
(Assignee)

Comment 20

17 years ago
benb, that is not true for me. I find folder-only-folder there w/ no trailing
slash. If we delete .mailboxlist will the server; regenerate the files. 
(Reporter)

Comment 21

17 years ago
> If we delete .mailboxlist will the server; regenerate the files.

Was that a question? Yes, the file keeps your subscription list only.

You can delete it, and the server will recreate it with good entries (I think -
make a backup to be sure), when you use Mozilla to resubscribe to the folders.
To be sure, do not check (subscribe) the folder-only-folders in Mozilla's
subscribe UI, only the msg-only-folders which are their childs. The
folder-only-folders should appear nevertheless.

Alternatively, you can manually delete all entires (lines) for
folder-only-folders in that file.
(Assignee)

Comment 22

17 years ago
Created attachment 44825 [details] [diff] [review]
proposed fix, v2
(Assignee)

Comment 23

17 years ago
This is basically the first patch w/ minor changes to not search when we have a 
folder only folder with no subfolders. As benb notes , .mailboxlist should have 
subscribed folder only folder with / at the end. When this is true we 
explicitly do a list for folder-only folder that sets the no-select flag for 
that folder. 

I think that uwtest account is messed up because the .mailboxlist on the 
server does not have correct entries. It worksfine for me on that other 
acct. seth, please review. 
sr=sspitzer

Comment 25

17 years ago
r=cavin.
(Assignee)

Comment 26

17 years ago
fix checked in.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 27

16 years ago
Verified on UW IMAP mail account for all the platforms:
Users can search msgs from the subfolders of the folderonly folder now. 
Verified.
Linux 10-15-05-0.9.4
WinNT 10-15-05-0.9.4
Mac OSX 10-15-11-0.9.4
Status: RESOLVED → VERIFIED
(Reporter)

Comment 28

16 years ago
verified here too. Thanks!
Product: Browser → Seamonkey

Updated

9 years ago
Component: MailNews: Search → MailNews: Message Display
QA Contact: huang → search
You need to log in before you can comment on or make changes to this bug.