I have noticed what appears to be a problem with Quickfolders PopUp menus.

I have a folder that has many subfolders. On my laptop, when I try and drag
something into the parent folder, the popup menu fills the complete height of
the window and the parent folder is obscured by the popup menu. Essentially,
the popup menu needs a vertical scroll bar to cater for these situations. 

bobj

Created an attachment (id=7723) [details]
3.14 prerelease 5

This is a prerelease with a hidden setting that is based on the minimum number
of menu items, once this number has been reached the menu will not cover the
whole area of the clicked tab.

In the test version I the threshold is hidden in the Tb configuration setting -
E.g. you can set the threshold to 40 using Tools > options (Edit > PReferences
on Mac)  >> Advanced > General > Config Editor:

in the search box above enter realignMinTabs to show a new setting:

extensions.quickfolders.folderMenu.realignMinTabs

(default would be zero which disables the new behavior)

change this to the appropriate number (e.g. 40). Consequently if the popup menu
has 40 items, the popup Menu is shifted to the right by 24px, so there is some
space to drop the mail into the parent folder itself.

Created an attachment (id=7724) [details]
example screenshot

This screen shot shows how a long menu will be shifted to the right when
dragging an Email onto it so that part of the tab remains available as drop
target.

Note that by (Mozilla's) design the menu will show a "down" button at the
bottom if there are more menu items than can be displayed on screen - to reach
them you have to drag the mail on top of this button. It is probably a good
idea not to have that many sub folders if you find that you have to drop mails
like this often as finding a drop target in a very long list will always slow
you down. A viable and recommended workaround would be some interim alphabetic
child folders, such as:

A-E
F-K
L-Q
R-X

in this way you can break up the tedious long Alphabetic list into 4 or more
parts making for a nicer experience.

By the way a scrollbar on the menu item is not the solution as it is not
designed for drag+drop. Scrollbars are only useful when you can click (there
are 5 different click targets on the scrollbar, and it has its own drag handler
for the "elevator").

(In reply to comment #0)
> I have noticed what appears to be a problem with Quickfolders PopUp menus.
> 
> I have a folder that has many subfolders. On my laptop, when I try and drag
> something into the parent folder, the popup menu fills the complete height of
> the window and the parent folder is obscured by the popup menu. Essentially,
> the popup menu needs a vertical scroll bar to cater for these situations. 
> 
> bobj
> 

I have a userChrome.css snippet to give long menus a scrollbar instead of the
default scrollbuttons, but as Axel said at the end of comment #2, a scrollbar
needs dragging, and if you are already dragging something when you decide you
need to scroll the menu in order to make your drag target visible, you have a
problem.

Here's the snippet anyway (it works in all current versions of SeaMonkey, and I
have found it useful in other circumstances); it is meant for the file
userChrome.css in the chrome/ subfolder of your profile, a file which does not
exist by defult. For more info, see http://kb.mozillazine.org/UserChrome.css
and http://kb.mozillazine.org/UserChrome-example.css

/*
 * give the menus a scrollbar when they are too high to be
 * displayed in full
 */
menupopup scrollbox, #contentAreaContextMenu scrollbox
  { overflow-y:         auto                    !important
  }
/*
 * eliminate scroll buttons at top and bottom of the menus
 */
menupopup autorepeatbutton, #contentAreaContextMenu autorepeatbutton
  { display:            none                    !important
  }

The fix/workaround is still problematic for long folder lists.

The list of folders with the offset now typically cuts the tab into two parts,
one visible and one obscured by the folder list. Unless one is careful to
always point to the left 1/4" or so of the tab it is still possible to drop the
message in the wrong location.

I suggest that the folder list should always be shifted to the left (or right)
edge of the tab. That way none of the tab is ever obscured. And when the folder
list won't fit to the right, just shift it to the left side.

It might also be worth considering using the Move To mechanism in Tb to access
the subfolders. It has the shortcoming of having to use the "File Here" item at
the top of a folder list, rather than just being able to drop on the current
subfolder list, but the folder lists are well behaved.

Created an attachment (id=7798) [details]
3.15 prerelease 11

Version using the end_before argument according to:
https://developer.mozilla.org/en-US/docs/XUL/PopupGuide/Positioning#The_position_attribute

works for me. When I move the tab so far to the right that the menu would be
truncated by screen edge the menu will pop over to the left edge of the tab.

(In reply to comment #4)
> It might also be worth considering using the Move To mechanism in Tb to access
> the subfolders. 
Can you elaborate how & where this would fit into QuickFolders? The "Move To"
command is a context command based on the Message (menu) so I do not see how it
could be integrated into QuickFolders in an intuitive way...

> It has the shortcoming of having to use the "File Here" item at
> the top of a folder list, rather than just being able to drop on the current
> subfolder list, but the folder lists are well behaved.
Yes this is one or the problems with manu-based folder hierarchie's which I
solved by completely re-programming my context menus displayed in the
QuickFolders multiverse. I wanted it to behave more like the Personal Bookmarks
toolbar...

You can even drag menu items to the QuickFolders bar so it is pretty universal.

Regarding the Move To suggestion:

Dragging a message to a Qf tab is logically equivalent to Move To on the
menubar.

The advantage of Move To is the smooth way it traverses the hierarchy of
sub-folders.

One downside to the Move To, folder "running", is the two ways of referencing
the target folder (1 - during navigation, 2 - "File Here" drop target
in list of sub-folders). It's also clumsy to get started.

It isn't clear to me why Move To doesn't just accept the mouse button release
on any folder as Qf does. Move To understands a folder icon is the target when
no folders are contained in the target folder.

I wouldn't care about the Move To issue if I didn't want to see change in
the Drop Over behavior in Qf don't see how to navigate a hierarchy via
initially "Drag Over" to a Qf tab.

So I was suggesting that drag and drop on a tab with subfolders just use the
code of Move To (with an improvement). 

(In reply to comment #7)
> Regarding the Move To suggestion:
> 
> Dragging a message to a Qf tab is logically equivalent to Move To on the
> menubar. The advantage of Move To is the smooth way it traverses the hierarchy of
> sub-folders.

When you use the term 'smooth', what do you exactly mean? The mechanism is
exactly the same, but drag & drop is harder than going through a menu with the
keyboard.

> One downside to the Move To, folder "running", is the two ways of referencing
> the target folder (1 - during navigation, 2 - "File Here" drop target
> in list of sub-folders). It's also clumsy to get started.

I think the biggest problem with "Move To" is that you might have to
potentially go through 4 or 5 levels before you hit the place where your target
folder is and that may feel cumbersome or slow compared to dragging to the
direct parent or even grandparent folder (less operations, less sideways
dragging). In my experience it is way easier to hit a vertical target than a
horizontal one that's why having the direct parent on the QF bar is the most
painless way of dragging to a child folder.

> It isn't clear to me why Move To doesn't just accept the mouse button release
> on any folder as Qf does. 

??? it is not a drag & drop operation, so if you use the mouse you will need a
full mouse click (down+up) for selecting a move target.

> Move To understands a folder icon is the target when no folders are contained in the target folder.

I think what you are trying to say is that menuitems accept drop but menupopups
(these are menuitems that have subitems and a little triangle on the side) do
not. Well that's the nature of the beast, they only do in my case because I am
such a talented hacker :P

> I wouldn't care about the Move To issue if I didn't want to see change in
> the Drop Over behavior in Qf don't see how to navigate a hierarchy via
> initially "Drag Over" to a Qf tab.

I look at it that way: Using Move to I generally have a much longer and
laborious journey for my files to get to their final destination (almost as bad
as using the folder tree), so I would only use it as an exception. If I find I
need the folder tree often (more than 2 times a day) then I know that I haven't
arranged my QuickFolders or mail filters correctly. I'd say the same goes for
using the "Move To" menu - you might find that you use it often for moving
files to related (sibling) folders, and often adding the father or grandfather
folder to the QF bar is a more efficient way to deal with this.

> So I was suggesting that drag and drop on a tab with subfolders just use the
> code of Move To (with an improvement). 

"use the code of" - that doesn't sound like a tangible requirement to me, as
far as I understand move to - you select one or more messages and use the
keyboard to show the complete acounts > folder tree.

So unlike what I do in QuickFolders, "move to" is not a drag and drop
operation, although it also shows folders. The only advantage that it has is
that it gives all accounts as top level folders - is this what you mean by "use
the code of"? It is better to make no assumptions on "how" something is coded,
easier to describe what you would like it to do. Are you suggesting a starting
point / drop target that expands into all accounts (and from there into all
folders)? Also, this discussion becomes increasingly off topic for this bug so
if it's not related to "long menu obscures QF tabs so they are not available as
drop targets", I would suggest to add a new bug, or contact me via email first
to help me find out what you actually mean.

I will leave the bug as RESOLVED FIXED for now.

Yes, 3.15 prerelease 11 has just the behavior I was looking for.

I had a bit more trouble with drag over not doing it's color with the 2-color
setting (after a few restarts for password adjustment tests), but with Standard
Palette setting it seems stable.

So, with these resolved I think I can trust the 4 row Qf tabs arrangement I was
using. It was just too easy to drop something in the wrong place before.

Thanks, top notch work.

(In reply to comment #9)
> Yes, 3.15 prerelease 11 has just the behavior I was looking for.
> 
> So, with these resolved I think I can trust the 4 row Qf tabs arrangement I was
> using. It was just too easy to drop something in the wrong place before.

Great. To avoid picking the wrong drop targets you can also try the new "folder
icon" feature - see [Bug 25708] for a bunch of icons:

https://quickfolders.org/bugzilla/bugs/attachment.cgi?id=7799