31814 - Improve Drag&Drop target selection indication

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[laurel]

Using mar13 b1 builds, all platforms

The indication that a folder has been selected for destination of a drag&drop of
a message is poor.  An outliner box draws around the folder sometimes, but this
is not consistent -- it is very easy to lose obvious indication of the selection
when dragging up/down through folder hierarchy.  Sometimes only half of the
outliner box shows, sometimes none. 

1.  Go to mail window, login to mail account.
2.  Select a message in a folder and drag it to a folder, but cross several
folders before releasing the mouse or making final destination selection.
3.  Repeat dragging different individual messages to various places in folder
hierarchy.

Result:  Obvious indication of the selection of destination folder is flaky. 
Sometimes the outliner box draws, sometimes it doesn't and sometimes it's only
partially drawn.

Comment 1

[laurel]

Oh, and the mac drags a big square outline along with the mouse cursor.

Comment 2

[Phil Peterson]

Sounds like a tree drag/drop issue. -> pinkerton

Comment 3

[Mike Pinkerton (not reading bugmail)]

this should go away when i make container drops suck less (scheduled item). don't 
file any more until i get to that feature.

Comment 4

[Mike Pinkerton (not reading bugmail)]

fixed. i had screwed up a comparison causing many dragovers of containers to be 
dropped on the floor.

Comment 5

[laurel]

Improved using mar30 commercial m15 builds all platforms.
However, two issues outstanding:
    1.  Mac still carries a confusing square box outline with all drag&drops
    2.  The destination selection now highlights the folder but has no outliner,
rather a partial bold underline.  Is this what is intended?

Let me know about these outstanding issues and whether a separate bug(s) should
be logged.  I see your other "master" tweak drop bug #9657 is marked fixed.

Comment 6

[Mike Pinkerton (not reading bugmail)]

the first thing is a separate bug and is a direct result of not having that 
information available from the DOM or JS, i'm not sure about the second. 

in the future, it's generally best to file new bugs so if they are issues we can 
track them separately rather than all lumped into one big uber-bug whose point 
gets lots quickly.

Comment 7

[laurel]

I'll mark this bug verified and open new bugs the lingering issues I mentioned.