Bug 495594 - Different drag cursor states when moving through various Dolphin's ares, cause different sites not accepting the drop
Summary: Different drag cursor states when moving through various Dolphin's ares, caus...
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: master
Platform: Manjaro Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-30 16:17 UTC by Michał Dybczak
Modified: 2024-10-31 14:28 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Drag-directions (412.42 KB, image/png)
2024-10-30 16:17 UTC, Michał Dybczak
Details
Gmail Gdrive (377.37 KB, image/png)
2024-10-30 16:18 UTC, Michał Dybczak
Details
Drag stop cursor (282.49 KB, image/png)
2024-10-30 16:19 UTC, Michał Dybczak
Details
Drag plus cursor (293.93 KB, image/png)
2024-10-30 16:19 UTC, Michał Dybczak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Dybczak 2024-10-30 16:17:55 UTC
Created attachment 175368 [details]
Drag-directions

***
I've been managing images on various Google Drive accounts for work and discovered several issues with drag-drop feature.

This requires some background info to understand the problem.

There are two various type of GDrive accounts:

1. Google Drive on Gmail account (can be free or paid, any person can have it, there are no requirements aside having Google personal account) - causes the least amount of issues. Drag-drop works there fairly OK, although I discovered that it is not enough to drag the file outside the Dolphin's window to the drop area. You need also to STOP while holding over the drop area and do another move to make see the drop cursor, which in this case is indicated with a HAND ICON. See the attached screenshot. This is however a weird mechanics on the site and KDE cannot do anything about it.

2. Google Drive on own domain (company's paid account) - is way harder to work with and causes more issues, because, as I discovered, the drag-drop works only, when moving earlier through other droppable areas in Dolphin where drag+ cursor appears (hand cursor as in previous case is not accepted by the site's mechanisms). See the screenshot with plus cursor.

Drag-drop does not work when:
- dragging over the below edge of the Dolphin
- dragging over the file info area
- dragging over the top edge of the Dolphin
- dragging over the areas with images where there is only drag-stop cursor (you cannot drop on files)
- dragging directly from Dolphin to the site over any edge of Dolphin

Drag-drop works only when:
-  it passes over the Dolphins droppable area (like other pane, locations panel) before descending to the draggable surface of the GDrive side. When there is two pane view, and you have location panel on the one side and file info panel on the other one, and the dragged file passes over the other pane on empty areas or over the location area (both are droppable areas in Dolphin where drag-plus cursor appears). However, sometimes, in rare cases even that doesn't work, so there is some unclear condition here.
In my case, as presented on the screenshot, in only works when I drag to the left. I assume, if the panels were reversed, only drag to the right would work.

Since the only difference between working is the kind of GDrive account, it has to mean, that there are various ways of creating droppable areas and which determines, how they interact with drag-drop feature.

1. On Gmail Gdrive the cursor double move (move, stop, move) is enough to trigger the droppable area on the site, the cursor is shown as hand. However, the fact that we see a hand cursor but dropping works, means that Gmail GDrive is more lenient and accepts this form of not refreshed drag state.

2. On company's account it happens, that the droppable area is more sensitive, and needs plus cursor, which doesn't shows automatically, when interacting with site's droppable area. The plus cursor most be activated before by passing over droppable Dolphin's areas like location panel. The site's surface accepts only this kind of cursor.

The various acceptable cursor icons suggest, that while dragging, there are various states and Gmail GDrive accepts first one (when cursor shows a hand), while Domanin (company's) Gdrive requires condition to be changed into drop, which is indicated as plus icon. So there are at least two states of the link when dragging file, which are shown by different cursor's icons.

I posted the screenshots to explain it visually.

Obviously, the site's droppable area seems to have different mechanisms on various accounts, and in the second case is not accepting the drag in a hand form. I don't know, how many ways are there to have droppable areas interacting with the cursor, but clearly, Plasma must improve the dragging states, so it would be robust and worked on all sites equally, without a long and confusing process of finding out, which moves work and which don't.


***

SUMMARY


STEPS TO REPRODUCE
1. Use Wayland.
2. Have Dolphin in two panel mode.
3. Have file info panel on one side.
4. Possibly have multiple monitors (not needed but helps to have Dolphin on one screen and browser's window on the other).
5. Possibly have various Google Drive accounts, especially important is to have company's drive with verified own domain. Without it, it would be impossible to test it. However, I hope that the fact that cursor icons are different, it is enough to discover what internal mechanism on KDE's side is causing the issue.

OBSERVED RESULT
Draging and dropping does not work consistently, because of the various areas that are crossed over when dragging a file. Most probably, the properties of drag are not correctly updated.

EXPECTED RESULT
Drag-drop works reliably, no matter if we drag over the left, right, upper, down edges or various areas.


SOFTWARE/OS VERSIONS
Operating System: Manjaro Linux 
KDE Plasma Version: 6.2.2
KDE Frameworks Version: 6.7.0
Qt Version: 6.8.0
Kernel Version: 6.6.58-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7840HS w/ Radeon 780M Graphics
Memory: 30.6 GiB of RAM
Graphics Processor: AMD Radeon 780M
Manufacturer: TUXEDO
Product Name: TUXEDO Sirius 16 Gen1

ADDITIONAL INFORMATION

I am aware of other drag-drop issues like this one: https://bugs.kde.org/show_bug.cgi?id=483645
I had it not so long ago, but was fixed.

Another problem, a different one, is that repeating unsuccessful drop, sometimes something breaks and dragging stops being possible. The only way is to either restart Dolphin or change the directory and back. I noticed that some breakages carry over to the other location, and only Dolphin's restart fixes it. The clear tell that the dragging broke at this moment is the lack of the cursor changes.

In this bug report, I want to focus on those dragging transformations showed by different cursor states and how various sites can accept one or only the other.

Also, I tested it only on Dolphin. I'm not sure if this is a general issue and if it can have different facets when interacting with various File Managers GUIs like Krusader.  I'm reporting it as a Dolphin's issue, because moving through Dolphin's UI causes the drop cursor to have different states, which influence the reaction of droppable surface on the site.

DRAG PROCESS SHOULD BE MORE RESILIENT AND WHEN CURSOR IS OUTSIDE OF DOLPHIN'S WINDOW, IT SHOULD BE UPDATED TO DROP-PLUS state, so the droppable surfaces on the sites recognized it correctly all the time - at least that is the theory.

I hope that someone who understand how the process is happening internally, can understand what I meant here and will be able to find the solution to this problem. Currently, working with Dolphin professionally is a pain, because of that drag-drop problem.
Comment 1 Michał Dybczak 2024-10-30 16:18:56 UTC
Created attachment 175369 [details]
Gmail Gdrive
Comment 2 Michał Dybczak 2024-10-30 16:19:28 UTC
Created attachment 175370 [details]
Drag stop cursor
Comment 3 Michał Dybczak 2024-10-30 16:19:49 UTC
Created attachment 175371 [details]
Drag plus cursor