1464540 - [Regression] Drag&drop drags the entire message list rows, makes drop target invisible

Status: NEW

(Core :: Widget: Gtk, defect, P2)

Description

[Ben Bucksch (:BenB)]

REGRESSION
OS: Linux
Build: TB 61

Reproduction:
1. Select 10 messages in the message list (thread pane)
2. Drag them on a folder in the folder pane

Actual result:
The entire message list rows stay under the mouse pointer.
You cannot see which folder your are over and where you're going to drop them.

Expected result:
Only an icon under the mouse pointer, like in TB 57.

Regression range:
Worked fine in TB 57, IIRC. Not sure when exactly it broke.

Comment 1

[Ben Bucksch (:BenB)]

Attachment: Screenshot, TB 61, Ubuntu Linux - shows bug

Comment 2

[Ben Bucksch (:BenB)]

This makes d&d pretty hard and the whole application on Linux rather unusable. Major regression. Therefore, requesting this to be a release blocker.

Comment 3

[Ben Bucksch (:BenB)]

Windows is better, but isn't ideal, either, as exactly the drop target folder is underneath the top message with 70% opaqueness, so you see only 30% of the target folder. OK for young people, but worse for older users, and bad usability for everybody.

Comment 4

[Richard Marti (:Paenglab)]

Attachment: Ubuntu-DnD.png

Tested on Fedora and Ubuntu (screenshot) with official TB 60.b6. This looks like always and the dragged items have some transparency and the target is highlighted when the mouse point over it. Yes, it could be more transparent but this didn't regress. The transparency is, as I know, not done in c-c code but in core. If this needs adjustment, this bug should go there.

I don't see your issue on Win 10 as the dragged items have an opacity of max. 30%.

Comment 5

[Ben Bucksch (:BenB)]

TB 52 doesn't do that. I'll attach a screenshot. It's not captured on the screenshot, but there's a small box icon on the bottom right of the mouse pointer, and a grabbing hand icon above the box. This signifies the D&D action.

Frankly, even your Ubuntu screenshot with the transparency for me is hardly usable, because the dragged email covers the drop target, which is what I try trying to hit. Yes, there's some transparency, but it's far harder to read than a clear text like on TB 52 on the screenshot that I attach.

Comment 6

[Ben Bucksch (:BenB)]

Attachment: Screenshot, TB 52 Linux - works correctly (there's also a little box bottom right of the mouse pointer, but it's missing from the screenshot)

Comment 7

[Ben Bucksch (:BenB)]

You have to admit that "Screenshot, TB 52 Linux" is the most usable of the 3, no? (Presuming the mouse pointer has the little DND icon)

Comment 8

[Richard Marti (:Paenglab)]

This was a Linux specialty as the other platforms always showed the items with some transparency. And Linux do it now too. So I'm used with this behavior and it's usable on my Linux distros.

Comment 9

[Tristan Miller]

(In reply to Richard Marti (:Paenglab) from comment #8)
> This was a Linux specialty as the other platforms always showed the items
> with some transparency. And Linux do it now too. So I'm used with this
> behavior and it's usable on my Linux distros.

I'm not seeing any transparency with Thunderbird 60.0 (64-bit, openSUSE Tumbleweed, KDE Plasma 5.12.5 with compositor disabled).  But transparency or no, this is a terrible usability issue, and if this is how things look on other OSes, then I think they need to be fixed also.

I have discovered that the old behaviour (or something very close to it) can be restored using the Config Editor.  Go to Edit->Preferences->Advanced->Config Editor… and change the value of the nglayout.enable_drag_images preference to "false".

Comment 10

[Camaleon]

Same here... and quite annoying. 
The bypass suggested in comment #9 does the trick (an standard icon is displayed instead the whole row). 
Side note: on Firefox 61.0.2 key "nglayout.enable_drag_images" is set to "true" by default and the setting performs the same way, i.e., when moving (drag and drop) a tab, a big icon is displayed instead.

Comment 11

[Richard Marti (:Paenglab)]

To them who see this issue, can you test this on Firefox with the default pref? Use the Bookmark library to test. If it's the same, this is a toolkit issue.

Comment 12

[Tristan Miller]

(In reply to Richard Marti (:Paenglab) from comment #11)
> To them who see this issue, can you test this on Firefox with the default
> pref? Use the Bookmark library to test. If it's the same, this is a toolkit
> issue.

Yes, I'm seeing it with Firefox 60.1.0esr (64-bit) on openSUSE Leap 15.0.  Does this bug need to be moved to the Core product, then?

Comment 13

[Camaleon]

(In reply to Richard Marti (:Paenglab) from comment #11)
> To them who see this issue, can you test this on Firefox with the default
> pref? Use the Bookmark library to test. If it's the same, this is a toolkit
> issue.

Mmm... you are right. 
On Firefox, the default setting "nglayout.enable_drag_images" is set to "true" and when dragging and dropping from bookmarks the same bad behaviuor occurs (the whole row is showed which makes difficult to see the final destination to place the item). 
I thought this setting was also referred to content preview when moving tabs, but seems not.

Comment 14

[Richard Marti (:Paenglab)]

Not sure if this is the correct component. Please move to the correct when wrong.

Comment 15

[Wayne Mery (:wsmwk)]

Walt, do  you see this issue?  If so, can you find the regression range using nightly builds?

Comment 16

[WaltS48 [:walts48]]

May not be an issue. The transparency occurs with DnD of bookmarks in Firefox on Windows and Linux.

For Thunderbird on Windows I see the transparency using 52.0.1 release, 57.0a1, 58.0a1, 59.0a1 and 60.0a1 in my tests.

For Linux.

Problem not seen using,

60.0a1
Build ID: 20180124030201
Built from https://hg.mozilla.org/comm-central/rev/fb8fb3ab759cec29abcf13446b6d03f64caf5670

On Linux I also see the document with a hand using 52.9.1 release, 
58.0a1 and 59.01 Daily's.

First see the transparency using,

60.0a1
Build ID: 20180127030201
Built from https://hg.mozilla.org/comm-central/rev/272f337b122a6317b96e37d2ca62d02dc5e620d3

No builds for 20180125 and 20180126 to test.

The folder highlights if you line up an email with the folder you want to drag it to, I got used to it while testing.

HTH

Comment 17

[WaltS48 [:walts48]]

FWIW

60.0a1 
Build ID: 20180124030201
Built from https://hg.mozilla.org/comm-central/rev/fb8fb3ab759cec29abcf13446b6d03f64caf5670
The default for nglayout.enable_drag_images;false

60.0a1
Build ID: 20180127030201
Built from https://hg.mozilla.org/comm-central/rev/272f337b122a6317b96e37d2ca62d02dc5e620d3
The default for nglayout.enable_drag_images;true

Comment 20

[Wayne Mery (:wsmwk)]

Ulrich, do you still see this in version 78?

Comment 21

[Ben Bucksch (:BenB)]

I just tested it with Thunderbird 78 on Ubuntu MATE. In the default config, I still see the bug, and it's still completely unusable, (even without transparency), as originally reported 3 years ago. The same screenshots as back then still apply. I cannot see the folder that I drag to. Still totally unusable.

With nglayout.enable_drag_images = false (not the default, I have to change it in Advanced Config Editor, see comment 9), it works as expected, I get a small drop icon and I can see the folder that I drag to.

Comment 22

[Camaleon]

Same here.
I still get the drag and drop issue when «nglayout.enable_drag_images = true».
Running Thunderbird 78.12.0 (package from Thunderbird's site) on Debian 9 (64 bits) with Xorg, XFCE (GTK+2) and plain desktop (no 3D nor fancy effects).

Comment 23

[Petruta Horea [:phorea], Desktop Test Engineering (back on Sep 5th)]

Changing severity to S3 since a workaround is available.