I was looking around the folders code and discovered a minor bug. If you create a folder with a dot in it (like test.box) RC will display a folder called test with a box sub-folder. That is all as it should be. The problem is that it allows you to drag and drop messages into the phantom folder and displays it as if it were a real folder. When you drag into the folder the message appears to go away, and of course doesn't appear in the phantom folder. When you refresh the folder that you dragged the message from the message reappears (which is good - at least it isn't lost forever). What should happen is that the phantom folder should be greyed out, and undraggable (and probably unselectable).
When you query IMAP for the folder list, it helpfully tags that folder as Noselect, but we don't do anything with that tag, or for that matter with any other tags (including such useful ones as HasChildren and HasNoChildren). I propose rewriting the folder getting routines to pass all of the tags through to the roundcube "layer" so that we can decide what to do about the presentation of these folders.
This requires the modification of iil_C_ListSubscribed in lib/imap.inc as well as _list_mailboxes and list_mailboxes in rcube_imap, and the various functions that call those functions (about 6 or so). So my question is does anyone have any reservations about me going ahead with this, and does anyone anticipate any cross IMAP server problems?
-Charles
estadtherr@gmail.com wrote:
Aren't IMAP implementations free to use characters other than "." to delimit folders in the hierarchy? I like the behavior, but I just want to make sure we're not making assumptions about folder delimiters.
You're right, but that's already all handled. I'm just dealing with the results of the LIST command.
-Charles
estadtherr@gmail.com wrote:
Aren't IMAP implementations free to use characters other than "" to delimit folders in the hierarchy? I like the behavior, but I just want to make sure we're not making assumptions about folder delimiters.
RFC 2060 says so, but we'll have to respect any delimiter that IMAP servers may use, and the "." is chief amoung those.
Unless we build a database containing real and display folder names.
mtu
Hi Charles,
I know the problem but I haven't seen that "noselect" tag. We should really take care of that and don't add links to those non-selectable folders. This would automatically disable them for selection as well as for dropping messages to them. If you're willing to take care of that, go ahead. I would also suggest to put the ul/li validation issue on hold since the main page does not validate anyway (like Brett pointed out correctly).
Regards, Thomas
Chuck, Charlie and Charles wrote:
I was looking around the folders code and discovered a minor bug. If you create a folder with a dot in it (like test.box) RC will display a folder called test with a box sub-folder. That is all as it should be. The problem is that it allows you to drag and drop messages into the phantom folder and displays it as if it were a real folder. When you drag into the folder the message appears to go away, and of course doesn't appear in the phantom folder. When you refresh the folder that you dragged the message from the message reappears (which is good - at least it isn't lost forever). What should happen is that the phantom folder should be greyed out, and undraggable (and probably unselectable).
When you query IMAP for the folder list, it helpfully tags that folder as Noselect, but we don't do anything with that tag, or for that matter with any other tags (including such useful ones as HasChildren and HasNoChildren). I propose rewriting the folder getting routines to pass all of the tags through to the roundcube "layer" so that we can decide what to do about the presentation of these folders.
This requires the modification of iil_C_ListSubscribed in lib/imap.inc as well as _list_mailboxes and list_mailboxes in rcube_imap, and the various functions that call those functions (about 6 or so). So my question is does anyone have any reservations about me going ahead with this, and does anyone anticipate any cross IMAP server problems?
-Charles
On Thu, 3 Aug 2006, Chuck, Charlie and Charles wrote:
I was looking around the folders code and discovered a minor bug. If you create a folder with a dot in it (like test.box) RC will display a folder called test with a box sub-folder. That is all as it should be. The problem is that it allows you to drag and drop messages into the phantom folder and displays it as if it were a real folder. When you drag into the folder the message appears to go away, and of course doesn't appear in the phantom folder. When you refresh the folder that you dragged the message from the message reappears (which is good - at least it isn't lost forever). What should happen is that the phantom folder should be greyed out, and undraggable (and probably unselectable).
Is there a reason for these phantom folders to exist?
-- 21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador
Martin Marques wrote:
On Thu, 3 Aug 2006, Chuck, Charlie and Charles wrote:
I was looking around the folders code and discovered a minor bug. If you create a folder with a dot in it (like test.box) RC will display a folder called test with a box sub-folder. That is all as it should be. The problem is that it allows you to drag and drop messages into the phantom folder and displays it as if it were a real folder. When you drag into the folder the message appears to go away, and of course doesn't appear in the phantom folder. When you refresh the folder that you dragged the message from the message reappears (which is good - at least it isn't lost forever). What should happen is that the phantom folder should be greyed out, and undraggable (and probably unselectable).
Is there a reason for these phantom folders to exist?
Yes, for example as container for subfolders. In file based IMAP servers, this is a physical folder holding mailbox files listed as subfolders. Because of being a folder and not a file, the IMAP server cannot write messages to it but unfortunately it is listed.
~Thomas
Martin Marques wrote:
Is there a reason for these phantom folders to exist?
Well they don't exist exactly. The "feature" here is that IMAP allows you to create a hierarchy without creating the folders in said hierarchy. You can see this by creating a new folder called "level1.level2.level3" (assuming that '.' is your divider). You will see that folder 2 is a subfolder to folder 1 and folder 3 is a subfolder to folder 2, even though only one new folder was created.
-Charles
-
Chuck, Charlie and Charles -
estadtherr＠gmail.com -
Martin Marques -
Michael Bueker -
Thomas Bruederli