Bug 417649 - No busy cursor on Wayland while the menu populate after we drag an image from Firefox and drop it on desktop
Summary: No busy cursor on Wayland while the menu populate after we drag an image from...
Status: RESOLVED DUPLICATE of bug 448867
Alias: None
Product: plasmashell
Classification: Plasma
Component: Containment (show other bugs)
Version: 5.18.0
Platform: Arch Linux Linux
: NOR minor
Target Milestone: 1.0
Assignee: Marco Martin
URL:
Keywords: wayland-only
Depends on:
Blocks:
 
Reported: 2020-02-14 16:54 UTC by Patrick Silva
Modified: 2023-04-09 22:48 UTC (History)
2 users (show)

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


Attachments
screen recording (1.03 MB, video/webm)
2020-02-14 16:54 UTC, Patrick Silva
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Silva 2020-02-14 16:54:42 UTC
Created attachment 126026 [details]
screen recording

SUMMARY
On Wayland the whole context menu is delayed in ~1s.

STEPS TO REPRODUCE
1. load the following link with Firefox
https://wallpaperaccess.com/full/112752.jpg
2. drag the loaded wallpaper and drop it on desktop
3. 

OBSERVED RESULT
Plasma takes some milliseconds to draw the context menu entirely.
Watch the attached screen recording please. 

EXPECTED RESULT
Plasma should draw the whole context menu immediately after we release the mouse button.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 5.18.0
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1
Comment 1 Nate Graham 2020-02-15 21:37:08 UTC
So what's the problem here? The fact that the menu changes a moment after it first displays? The same thing happens on X11. I think what's going on is that it first displays the basic menu immediately, then it takes a moment to look at the contents of the URL to determine what to do with it, at which point it's able to display context-appropriate actions.

Showing the menu with context-appropriate actions instantly therefore isn't possible because the URL needs to be examined first, which necessitates network activity that might be slow.

On X11, the cursor changes to a busy cursor during this time. It should do that on X11 too. I recall a recent patch that might have fixed this recently; do you think you could test again with Neon unstable?
Comment 2 Bug Janitor Service 2020-03-01 04:33:12 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 3 Patrick Silva 2020-03-01 16:34:15 UTC
This report is about X11. Screen recording on Plasma Wayland is still impossible.
As we can observe in attached video, no busy cursor appears when mouse button is released.

(In reply to Nate Graham from comment #1)
> So what's the problem here? The fact that the menu changes a moment after it
> first displays? 
yes, I thought that such behavior was a problem. But your explaination makes sense to me.

> On X11, the cursor changes to a busy cursor during this time. It should do
> that on X11 too. I recall a recent patch that might have fixed this
> recently; do you think you could test again with Neon unstable?
On Neon unstable I see busy cursor on X11 but I don't on Wayland.
Comment 4 Nate Graham 2023-04-09 22:48:16 UTC
If you drag to the desktop, wait 1 or more seconds, and then release, you'll see the busy cursor and the menu. Same root cause as Bug 448867.
Comment 5 Nate Graham 2023-04-09 22:48:30 UTC
*** This bug has been marked as a duplicate of bug 448867 ***