| Summary: | Single clicking the top of the chromium window while it is left or right snapped causes it to jump to the middle of the screen | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | pmquinn5 |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | nate, orko |
| Priority: | NOR | ||
| Version First Reported In: | 5.27.7 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| URL: | https://bugs.chromium.org/p/chromium/issues/detail?id=1488088&q=Jumps&can=2 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Behavior
Same behavior, but with sys titlebars enabled firefox jump to original position when dragging |
||
|
Description
pmquinn5
2023-09-27 18:13:59 UTC
Created attachment 161915 [details]
Behavior
Created attachment 161916 [details]
Same behavior, but with sys titlebars enabled
*similar behavior, I should have said Can reproduce, but this is in fact a bug in Chromium. What's happening is that the click is triggering "un-tile me!" mode. However because you're not dragging, it doesn't stick to your cursor but rather immediately reverts to the position it had before it was tiled. Other apps only leave tiling mode when dragged; doing it on mere click is unexpected and caused by a bug in the app itself. Please report this issue to Chromium at https://bugs.chromium.org/p/chromium/issues/. Thanks! Reopening this as after further investigation, it's only reproducible on plasma. I'm unable to repro on GNOME. That doesn't necessarily mean it's a KWin issue. It could be that Mutter has a workaround for this, or lacks the feature in KWin that interacts with the bug in Chromium that causes the feature. Please report it to the Chromium devs. Thanks a lot! That makes sense, thanks. For reference here's the ticket I cut to the chromium devs in September: https://bugs.chromium.org/p/chromium/issues/detail?id=1488088&q=Jumps&can=2 Unfortunately, the issue is getting zero traction even for triage on the chromium side. I'd speculate that this may be due to the fact that this only affects KDE plasma, and so chromium developers using GNOME would need to switch to repro. I understand that this is a chromium issue, but this only affects KDE Plasma users. As a result, it's a significant user experience impact for any plasma users who are using any chromium based browser, be it chrome, chromium, brave, vivaldi, etc. I imagine that's a significant chunk of plasma users. Given that there's no traction on the chromium side, I'm bumping this issue to ask about whether it falls within KDE policies to at least do the initial triage for this issue. This issue impacts a tiny fraction of all chromium users, but a significant portion of KDE users are impacted. So even though the responsibility for triage falls on chromium, as a practical matter that simply is not happening, so it may behoove KDE to do the initial triage here. And as for evidence of lack of traction, I have bumped the chromium issue twice a month since October. JFYI bumping doesn't help anything, it just annoys all the people CCd on the bug report and makes them *less* likely to want to fix it. FYI, it's looking like this is a Plasma issue after all: https://issues.chromium.org/issues/40934397#comment14 Any help that can be provided in narrowing down the root cause would be appreciated :) Created attachment 166734 [details]
firefox jump to original position when dragging
I think there are potentially 2 issues here. 1. Whenever window dragging is started by the compositor, should it revert it to the original position? That directly seems to be the cause for the "jump" which is seen. It can be seen even when dragging another app, e.g. firefox, where a flicker is seen due to an initial jump when the dragging starts. See attached video: https://bugsfiles.kde.org/attachment.cgi?id=166734 2. The plasma wayland compositor starts the window drag and un-tiles immediately if an app sends `xdg_toplevel.move` in response to `wl_pointer.button`, as noted in https://issues.chromium.org/issues/40934397#comment14. As per https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:move it seems that sending `xdg_toplevel.move` from the app "in response to some sort of user action like a button press" is a valid operation. Could the plasma wayland compositor delay the actual dragging and consequently un-tiling only after the mouse is moved ? Ok thanks, re-opening. This issue should be fixed in 6.1. |