302109 - entire line not highlighted for folder names when dragging/dropping msgs to folders

Status: RESOLVED WORKSFORME

(Thunderbird :: Theme, enhancement)

Description

[philiptdotcom]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Once again, I'm disappointed to find that the wisdom of the Netscape 4.76
usability team is being forgotten/ignored.

When dragging a mail msg to a different folder, in Netscape 4.76, the entire
line on which the folder name is highlighted, making it MUCH EASIER (requiring
less precision) to drop dragged e-mail msgs to the new folder.  In Thunderbird,
ONLY the TEXT of the folder name is highlighed, forcing hand(/mouse)-eye
coordination to be more difficult than it it used to be/has to be (and there for
"should be").

Please remember the wisdom of past designers & re-implement this!

Thanks for considering this suggestion!

Reproducible: Always

Steps to Reproduce:
1. Open Thunderbird

2. Drag a message to a different folder

3. Voila! (See image attachment that compares NS476 to Thunderbird's handling of
this issue.)

Actual Results:  
only folder text is highlighted (harder to deal with)

Expected Results:  
entire line where folder name is is highlighted (easier to deal with)

I'm going to attach a file that demonstrates the difference in NS476 and
Thunderbird.

(Why can't we attach a file directly from this error report?  Seems like I
remember seeing something that will let me attach a file, but only after this is
submitted & I look at it later.... "??????????")

Comment 1

[philiptdotcom]

Attachment: compares NS476 handling of folder highlighting to that of Thunderbird

Comment 2

[zug_treno]

Related to Core bug 80837 and Suite bug 100510?

Comment 3

[David :Bienvenu]

I've also noted that dragging a folder doesn't scroll the folder pane anymore.

A related issue is that just mouse clicks require that you be on the folder name, not just the folder line, for the select to work.

Comment 4

[Brian Hauer]

While I did not previously use Netscape, my previous e-mail client behaved the same way as you describe: the entire row on for each folder was the drop target for message drag&drop operations.

Furthermore, and I think just as important, there was no vertical gap between folders' drop targets.

That is to say, in Thunderbird 3, message drag&drop operations are frustrated by two related issues:

(a) Short folder names are difficult to target because the width of their drop target is only as wide as the name itself.

(b) The drop target's height is only as tall as the text.  There is a roughly 4-to-5 pixel vertical gap between drop targets.

I am not suggesting that the visual white-space gap between folders be reduced.  Rather, I am asking that the spacing be made the equivalent of "padding" rather than "margin" (to use HTML/CSS lingo).

Basically, the folders list should be a more-or-less seamless stack of targets.  I can think of no compelling argument for having empty space within the folder list (outside of cases where the row in question is not a drop target at all, such as the names of accounts) that results in an aborted drop.  If the user wants to abort a drag&drop of a message, they can simply move the mouse out of the folder list panel.

Comment 5

[Brian Hauer]

My apologies: I was wrong above when I said that short folder names are more difficult to target than long names.  The entire width of the column is, in fact, included in the target area.

The problem remains that the drop target's height is only as tall as the text's dimensions.  There is a non-trivial many-pixel vertical gap between the drop targets for folders that makes drag & drop require an unnecessary amount of mouse dexterity.

Aside from being incorrect about the width of the drag target, I believe the rest of my comment above still applies.

Comment 6

[Brian Hauer]

Just upgraded to Thunderbird 5 here, complete with the new Windows 7 theme.  A few things of note related to this bug:

1. Unfortunately, the drop target for folders remains frustratingly small.  As with Thunderbird 3.x, there are about 8 vertical pixels of "dead zone" between each folder.  I remain firmly of the opinion that there should be -zero- vertical dead zone between each folder.  The folders should be a seamless stack of drop targets.  If the user wishes to abort a drag-and-drop operation, they move the mouse cursor away from the folder tree.

2. In the new Windows 7 theme, the drop target is not highlighted in any fashion whatsoever.  The only indication that a folder is a valid drop target is the mouse cursor changing away from the "invalid drop target" cursor.  This seems like an oversight in the Windows 7 theme and unfortunately makes an already frustrating operation (due to the dead zones described above) still more frustrating due to fewer visual cues.

Comment 7

[swbrains]

This issue has plagued TB for versions.  I must add my +1 to this issue -- TB should assume a more standard hover/highlight scheme consistent with mainstream apps such as Windows Explorer.  The entire folder row height should be active as the drop target. Currently I find that as much as half of the time my drop operations do not execute because I slightly missed the target folder text. Also, the entire row cell should be highlighted when hovered over during a drag operation to make it clear which row is the currently selected target.  

I was hopeful this would be corrected in a major release such as 5, but disappointed it was not.  It also doesn't appear to be corrected in the version 6 beta at this point.

Comment 8

[Brian Hauer]

This is a daily frustration for me in my routine organization of e-mails.  Even with many message filters, a great deal of e-mail needs to be filed by hand.

I wanted to add that the decrease in functionality I cited above--that in the Windows 7 theme the row highlight has been removed--is particularly frustrating when dragging many messages in a single operation.

When dragging multiple messages at once, the visual clutter is greater.  It is especially difficult to see the drop-target's folder name through the noise of several message synopses.

Having no drop-target highlight is frustration layered on top of the existing frustration of the dead zones between rows.

If you don't understand, please take a moment to try a few dozen message filing drag-and-drop operations yourself.  For extra points, try to complete each operation in less than 2 seconds.  If you happen to have the mouse precision of a 3D gamer, maybe you will get a high frag count.  Observe friends and family doing the same; see how many times the operation is aborted because the user wasn't precise enough.  Consider playing the "Humiliation!" sound bite every time the operation fails.

Comment 9

[Jim Porter (:squib)]

(In reply to Brian Hauer from comment #8)
> I wanted to add that the decrease in functionality I cited above--that in
> the Windows 7 theme the row highlight has been removed--is particularly
> frustrating when dragging many messages in a single operation.

I don't see this in Thunderbird 6. The rows highlight as expected. In fact, for the Aero theme, this bug is fixed (though we could probably use some tweaks to it). I believe this was broken in Thunderbird 5, though.

Richard, do you mind taking a look at this? In particular, I notice that for Windows 7, we should probably be using the same look as when a row is selected, if Windows Explorer is anything to go by. Right now we just have a mostly-solid blue box, which is ok, but not great. Other platforms should be pretty easy to handle too, though note that I don't have a Mac, so I can't test the changes on that platform.

Comment 10

[Jim Porter (:squib)]

Moving to the Theme component for tracking purposes.

Comment 11

[Brian Hauer]

Jim, you're absolutely right about the highlight.  I had not even realized Thunderbird 6 had been released.  I just applied the update and the drop-target hover highlight is being painted correctly.  My sincere apologies for the false alarm on the highlight painting.

However, to clarify, I believe this bug is more about the need to increase the size of the drop target to cover the entirety of the row.  The drop-target painting--or lack thereof--was just an unfortunate additional twist in Thunderbird 5.

The gap between each drop target remains.  Similar programs, e.g., Windows Explorer, have no such gap between drop targets in their tree pane.

As always, thanks to you guys for your hard work on fixing these things.

Comment 12

[Richard Marti (:Paenglab)]

(In reply to Jim Porter (:squib) from comment #9)
> Richard, do you mind taking a look at this? In particular, I notice that for
> Windows 7, we should probably be using the same look as when a row is
> selected, if Windows Explorer is anything to go by. Right now we just have a
> mostly-solid blue box, which is ok, but not great. Other platforms should be
> pretty easy to handle too, though note that I don't have a Mac, so I can't
> test the changes on that platform.

This is again a limitation of the treechildren. The droptarget doesn't work on the whole treechildren. It works only on treechildren::-moz-tree-cell and here I can't give borders. this would make the whole treechildren taller and would also make other problems for selected treechildren. This also explains why it's a gap between the targets.

On XP I can confirm the drop highlight is only on text. I'll look if I can do something to augment it to the whole width.

Comment 13

[Richard Marti (:Paenglab)]

Filed bug 687968 on Toolkit to highlight the whole row.

Comment 14

[swbrains]

I think it's important to note that there are two issues here, and bug 687968 and its resolution appear to only address one of the issues -- the visual side of highlighting the hovered-over row.

The other issue the part that Brian Hauer refers to (and I seconded): "(b) The drop target's height is only as tall as the text.  There is a roughly 4-to-5 pixel vertical gap between drop targets."

This second issue is the *real* annoyance.  While highlighting the entire hovered-over row helps, it's not as effective if the target row is only considered a valid drop zone when the mouse pointer is with the actual text height, rather than anywhere (vertically) within the row -- even above/below the top/bottom of the folder title text itself.  When I applied the the fix in 687968, it appears to change how the hovered-row is highlighted, but the mouse still must be within the actual text height to have TB consider the message to be ready for dropping. If you drop the message above the text or below the text but still within that physical row, the message is not moved to that folder.  The real fix here would be to allow TB to consider the entire folder row height, not just the height of the text in that row to be a valid drop area.