| Summary: | Kwin draws 1px overlay on the left screen border | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | grmat |
| Component: | input | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 4pp4, agrinev98, andrius, gst402, jk, john.ettedgui, k2squared, kdebugs.81do7, kdebugs, kishore96, leguen.yannick, mahen, nate, simonandric5, tzt, woroof |
| Priority: | NOR | Flags: | mgraesslin:
Wayland-
mgraesslin: X11+ mgraesslin: ReviewRequest+ |
| Version: | 5.10.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| URL: | https://phabricator.kde.org/D6304 | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=387775 https://bugs.kde.org/show_bug.cgi?id=390654 |
||
| Latest Commit: | https://commits.kde.org/kwin/6267d597311ccea26a8e70d57bd730ad13d146c2 | Version Fixed In: | 5.10.3 |
| Sentry Crash Report: | |||
| Attachments: |
screenshot of the overlay
xwininfo output |
||
Created attachment 105851 [details]
xwininfo output
Also another quick test is right clicking the workspace. Expected behaviour is to open the menu, which doesn't work on the left border. I can also confirm this bug. I'm seeing this on openSUSE Tumbleweed since Plasma 5.10.0 update. I confirm this bug too in KDE Neon User Edition, and I've noticed it since upgrading to Plasma 5.10.0 For me the steps to reproduce are: 1. Maximize window (in my case Chromium) 1a. If you have a panel to the left, then fullscreen the window. 2. Go to a page which is large enough to vertically scroll. 3. Bring mouse cursor to the left edge of page. 4. Vertically scroll Actual results --------------- Page does not vertically scroll Expected results ----------------- Page vertically scrolls It works fine on Plasma Wayland, only on X11 session. *** Bug 380492 has been marked as a duplicate of this bug. *** *** Bug 380807 has been marked as a duplicate of this bug. *** *** Bug 381112 has been marked as a duplicate of this bug. *** According to bug 380492, it is possible to workaround this by disabling the left-edge touchscreen action. I have no edge triggering set up, the bug is still there. I can confirm this bug. Another test and broken use case: 1. Unlock Widgets, right click on task bar panel, select Panel Options -> Panel Settings, and, using Screen Edge button, drag the panel to the left. Then close Panel Settings. 2. Push the mouse to the left edge and hover over icons of applications or launchers in Task Manager widget. Expected: hovered icon is highlighted when mouse pointer is pushed to left edge. Actual: icon is not highlighted and so no preview appears. Also I can confirm the workaround from comment 10 works: 1. Go to System Settings -> Desktop Behavior -> Touch Screen. 2. Click on the box in the left-hand side of the screen preview and select No Action (Toggle Window Switching is selected by default). 3. Apply settings. 4. Restart the desktop environment. This is essential because the workaround doesn't work right away. I've rebooted the system to restart the DE. (In reply to woroof from comment #12) > 4. Restart the desktop environment. This is essential because the workaround > doesn't work right away. I've rebooted the system to restart the DE. Can simply run "kwin_x11 --replace". It worked for me. Technically this is not a regression. This behavior has been present for as long as screenedges exist and hardly any bug got reported for it. As soon as one has a screenedge configured for an edge it takes away one pixel. On Wayland we do not depend on windows for it, so there it is not a problem. Martin, this is not about screenedges, but about the new touchscreen support. (In reply to Christoph Feck from comment #10) > According to bug 380492, it is possible to workaround this by disabling the > left-edge touchscreen action. Thanks, can confirm it does help. Bad defaults then (In reply to Martin Flöser from comment #14) > Technically this is not a regression. This behavior has been present for as > long as screenedges exist and hardly any bug got reported for it. As soon as > one has a screenedge configured for an edge it takes away one pixel. kwin should differentiate between pointer and touch input, also IMHO the default should not take away one screen edge from every user when the vast majority doesn't even have a touchscreen. (In reply to Christoph Feck from comment #15) > Martin, this is not about screenedges, but about the new touchscreen support. Yes and touchscreen support is implemented through screenedges. It's the same technology. *** Bug 380957 has been marked as a duplicate of this bug. *** (In reply to Martin Flöser from comment #17) > Yes and touchscreen support is implemented through screenedges. It's the > same technology. Yet the default behaviour changed and there have been already two bug reports about it. I think I need to explain a little bit more. We do have the functionality of screenedges since 4.0 or even longer which is about a decade now. The implementation relies on input only windows with a border of 1px. This has always been like that. Since the introduction it was combined with a default corner enabled by default. In all those years hardly anybody complained about the fact that this steals mouse clicks. I only remember one fellow dev to mention it. The implementation is even smart enough to have the windows removed when there is a fullscreen window. So e.g. gaming in a fullscreen window is not affected by this problem. Given the data we had there was no indication that this would result in problems. We are now also caught in between a hard and a rock place. I understand that you would like the default to change, but users with touch screens will disagree. Such a functionality must be provided out-of-the-box. Given that there is a simple workaround for affected users this has not a high priority. That is we will not revert the change. I will investigate another solution which I wanted to use anyway, but there is no guarantee that this will be provided as an update to 5.10. (In reply to Martin Flöser from comment #20) > In all those years hardly anybody complained about the fact that this steals > mouse clicks. I only remember one fellow dev to mention it. The > implementation is even smart enough to have the windows removed when there > is a fullscreen window. So e.g. gaming in a fullscreen window is not > affected by this problem. > Something must have went wrong then. Gaming in full screen window is affected. Maybe that's why we have way more bug reports now. I tried 0ad and it is hardly playable when you can't scroll by moving mouse all the way to the left edge. > Something must have went wrong then. Gaming in full screen window is
> affected.
That was the important missing piece of information. I think I have a bug fix.
Thanks for your explanation and further investigation. (In reply to Martin Flöser from comment #20) > > In all those years hardly anybody complained And now there is a bug report with 5 duplicates in two weeks. I believe that you are familiar with the implementation but the change in behaviour *was* introduced lately. > Given the data we had there was no indication that this would result in > problems. That's why we write these bug reports ;) > I > understand that you would like the default to change, but users with touch > screens will disagree. I don't want anything less than demanding to change the defaults so they suit me. > Given that there is a simple workaround for affected users this has not a > high priority. That is we will not revert the change. I will investigate > another solution which I wanted to use anyway, but there is no guarantee > that this will be provided as an update to 5.10. That doesn't really matter much. I'm on rolling release anyway and there is no problem for now, because I can just simply switch it off. I just thought it is not a good idea to discriminate all the users having a mouse in favour of the few with touch screens. Git commit 6267d597311ccea26a8e70d57bd730ad13d146c2 by Martin Flöser. Committed on 26/06/2017 at 20:06. Pushed by graesslin into branch 'Plasma/5.10'. Properly block the edge also for touch screen edges Summary: There was a regression introduced with bug fix eec6afe6 which added a for pointer events only check also to doUpdateBlocking. Do to that the edge blocking mechanism didn't work for touch edges. FIXED-IN: 5.10.3 Test Plan: verified with xwininfo that there is no longer a window when in full screen. Activated edges through touch and pointer Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D6304 M +0 -3 plugins/platforms/x11/standalone/edge.cpp https://commits.kde.org/kwin/6267d597311ccea26a8e70d57bd730ad13d146c2 >Version Fixed In: 5.10.3
No, it's not! Just updated my neon to 5.10.3 and it's still here.
(In reply to fxshift from comment #25) > >Version Fixed In: 5.10.3 > No, it's not! Just updated my neon to 5.10.3 and it's still here. The only way to remove it is to disable touch screen swipe gestures in the settings. (In reply to fxshift from comment #25) > >Version Fixed In: 5.10.3 > No, it's not! Just updated my neon to 5.10.3 and it's still here. It wasn't committed to 5.10 branch, only to master. (In reply to Andrius Štikonas from comment #27) > (In reply to fxshift from comment #25) > > >Version Fixed In: 5.10.3 > > No, it's not! Just updated my neon to 5.10.3 and it's still here. > > It wasn't committed to 5.10 branch, only to master. Sorry I'm taking it back... Concerning the fix: it makes sure that the edges are not active for active fullscreen window. For all other kind of windows it is still there. E.g. if you have a maximized window it's there. If you are not satisfied with this solution please use the workaround of disabling the edge. *** Bug 384269 has been marked as a duplicate of this bug. *** kwin_x11 5.10.5 (Debian) and the bug is still here. The edge works when there is a fullscreen window, but not in any other case. I have no actions configured on any edge nor corner, and yet the 1px wide window is covering the left edge of my screen. ... However, after reading duplicate bug reports, and after setting edge actions (both toch and pointer), restarting kwin, and then unsetting the options, I got rid of the 1px border. So there may be another bug in the configuration or edge actions setup. When there is no action configured for pointer, but there is an action for touch, then the 1px window is created, but does not ignore (pass-through) events from pointer. Under Wayland (not X11) I get a 1 px dead line at the bottom of the screen (for instance, prevents from maximizing / minimizing windows easily by moving the mouse to the extreme bottom of the window). Is it related according to you or should I file a distinct bug report ? It occurs only under Wayland, under both Plasma 5.11.x and 5.12.0, KDE Neon user edition, Intel HD 530. typo : to the extreme bottom of the *screen* (In reply to Mahendra Tallur from comment #33) > Is it related according to you or should I file a distinct bug report ? Completely unrelated, please file a distinct bug report. |
Created attachment 105850 [details] screenshot of the overlay I recently upgraded to 5.10 on two machines and both show this new behaviour: There is a 1px wide overlay which makes interactions with the underlying (maximised) windows impossible, e.g. when trying to select text or clicking buttons. I often push the mouse to the edge because it is faster than aiming. Appended is the output of xwininfo and a screenshot from spectacle capturing the "Window Under Cursor". xkill of the id that is shown in xwininfo reveals that this belongs to kwin. I think this behaviour can be easily reproduced by maximising windows and move the mouse to the left edge of the screen. E.g. if done with konsole, the mouse cursor changes, xwininfo and spectacle also work well.