36583 - Folder config case where Drag&Drop selection appears diffused.

Status: VERIFIED INVALID

(Core :: XUL, defect, P3)

Description

[laurel]

Using apr19 m16 commercial builds, all platforms

There is still a case where drag&drop a message to an open folder hierarchy will
cause the target folder selection to go a bit weird.

1.  Login to mail account and setup a folder hierarchy similar to this, where a
folder has subfolders, but there is at least one subfolder immediately below the
root which has no subfolder of its own, then the last subfolder of the root does
have its own subfolders... something like this:

    Folder A
    |
    --- Foobar One (this has no subfolders)
    |
    --- Foobar Two (this has no subfolders)
    |
    --- Foobar Three  (this has subfolder(s))
        |
        ---  Sub1 of foobar three

2.  Expand folder A, or the root of this mini hierarchy but leave Foobar Three's
hierarchy collapsed.

    Folder A    EXPANDED
    |
    --- Foobar One (this has no subfolders)
    |
    --- Foobar Two (this has no subfolders)
    |
    --- Foobar Three  COLLAPSED

3.  Select a message in the account's inbox and drag it to Folder A in the
example.

Actual result:  What you'll see is the highlight/grey line appear at Folder A
and the bold underline of selection target appear under Folder Three.  The
selection of the one single folder for destination is somewhat diffused and
selection appears to encompass the subhierarchy.  Moving the mouse around a bit
will often move the bold line to the proper folder (Folder A).

Expected result:  One single and very clear, clean selection of the target folder.

Note:  I'm not sure if you want to include this scenario as part of your general
"tweak drag and drop" bug #9657...

Comment 1

[Mike Pinkerton (not reading bugmail)]

icky. looks like a separate bug to me.

Comment 2

[Peter Trudelle]

[nsbeta2-]

Comment 3

[Peter Trudelle]

Mass-moving all nsbeta2- bugs to M20

Comment 4

[Mike Pinkerton (not reading bugmail)]

we need to fix this for ship, nominating appropriately

Comment 5

[Mike Pinkerton (not reading bugmail)]

this is the intended behavior. the line under folder three is to show that it 
will go in folder A at the end of its child list if dropped on folder A. However, 
this particular tree doesn't have the concept of inserting something into the 
tree between the items.

Marking this INVALID. If you want a bug that drag feedback in general needs to 
support trees where things can only go into folders, not into the tree, file a 
new one.

Comment 6

[laurel]

I think that if this is intended behavior, it is still confusing, not clear 
behavior for user. Will open a new bug as you suggested, although I'm not sure
why we can't just change the summar to this one... new one logged as bug 47105.

Comment 7

[laurel]

Marking verified (invalid).