When moving mouse over inactive Kitty windows, text is selected as if the mouse button is pressed #7381
Comments
|
Does not reproduce for me with those steps using current kitty version |
|
This happens still in kitty 0.35.2 Only happens in wayland sessions. I can reproduce consistently... Open kitty with 3 internal windows. |
|
Still doesnt repro for me with those steps. And wayland is meaningless, what actual compositor. |
|
Sorry here is the debug info |
|
This is the input log, first click is clicking in the top kitty window, after last click text selection is enabled in the last (bottom right window). Also closing kitty internal windows does not clear selection. It looks like kitty thinks the left button is being held down. |
|
Doesnt repro for me in kde wayland. Your input log ends with which shows that kitty thinks the button was released and the drag (aka selection) finished. |
|
Do have any tips on how to start tracking down what is going on? I tried various versions back to 0.21.0 and it reproduces consistently. The other user from (#7382) was using KDE 5.27.5 and 5.27.11 with wayland, I am using KDE 6.1.2 with wayland. There is almost zero likely hood we have wayland versions in common as debian is far out of date. The issue only happens in Kitty, I have never experienced the issue with any other application or terminal (Konsole/Alacritty). |
|
All the mouse related code is in mouse.c and wayland code is in wl_init.c and wl_window.c. Start with mouse.c and some prints see whats going on. |
|
Thanks, I think I found it. It is when the mouse comes back from the external focus. The click event in the window registers a click but never releases. Subsequent clicks register release but the original one has not. It runs this code when mouse re-enters window But never runs the deselect code |
|
This is the input log with debug output, I have added comments to clarify what I am doing. You can see the "handled as drag end" is missing when clicking back in the window. I am not well versed in C, but let me know if you need more and I can give it a go. |
|
I dont follow in your first comment you say no release event is And are you doing the following:
because I cannot replicate. Do you have some non-standard kwin settings? |
I'm also still seeing the same thing as the original issue, but now on |
Here maybe this helps? This code This code is never called.... I dont see how this can be unclear the message from
No non standard settings, its actually a fresh install. This also happened for me on KDE 5.27.11 on Gentoo and I can repo it on Debian 12 as well using stock settings. EDIT:
Sorry I missed this point. Mouse is released inside kitty window before moving to Firefox. Mouse is released in Firefox window before moving back to kitty. There is no weird behaviour being performed. Just moving back to kitty and clicking the window again. |
|
On Mon, Jul 08, 2024 at 12:23:59PM -0700, drammelt wrote:
> I dont follow in your first comment you say no release event is delivered leaving a persistent selection. In your input2.txt log you have marked the release event as bogus. What's bogus about it? Are you saying you didnt actually release the mouse? Or that the release event didnt end the selection? Or something else?
I don't see how that is unclear, check every other mouse release they call the function and run
`printf("handled as drag end\n");`
The mouse click that comes back into the window never calls this, it is an orphaned select.
What is a mouse click that comes back into a window? What are you
actually clicking? There is no such thing as a click. There are press
and release events. A "click" is synthesized from a press followed by a
release. Which one are you talking of, press or release?
Here maybe this helps?
```
+++++ SELECT START +++++on_mouse_input: press button: left mods: none grabbed: 0 handled_in_kitty: 1
...
Release mouse_button: 0 mods: none grabbed: 0
on_mouse_input: release button: left mods: none grabbed: 0 handled_in_kitty: 0
```
This code
```
mouse_selection(Window *w, int code, int button) {
...
switch((MouseSelectionType)code) {
case MOUSE_SELECTION_NORMAL:
printf("+++++ SELECT START +++++");
screen_start_selection(screen, w->mouse_pos.cell_x, w->mouse_pos.cell_y, w->mouse_pos.in_left_half_of_cell, false, EXTEND_CELL);
break;
```
This code is never called....
```
mouse_selection(Window *w, int code, int button) {
...
if (global_state.active_drag_in_window) {
printf("+++++ SELECT END? +++++\n");
if (button == -1) { // drag move
...
else if (action == GLFW_RELEASE && button == global_state.active_drag_button) {
w = window_for_id(global_state.active_drag_in_window);
if (w) {
end_drag(w);
printf("handled as drag end\n");
dispatch_possible_click(w, button, modifiers);
return;
```
I dont see how this can be unclear the message from
` printf("handled as drag end\n");`
Is not in the logs, No other message from the mouse even function is in the logs, it never happened. Its a bogus message because kitty never handles the event. I am guessing that message comes from GLFW since the text is not in kitty source.
What on earth. GLFW is embedded in kitty's source. As I said originally
look in wl_window.c and wl_init.c.
I *think* what you are trying to say is that the release event is not
trigerring an end of selection. The relevant control for that is line
792-3 in mouse.c. Put some prints in there to see which if fails. Is it
because of active_drag_button or active_drag_in_window. I would guess
its active_drag_in_window. This is set in a few places in mouse.c and
glfw.c put some prints in there and check when it is changed.
If I had to guess, I would say it's happening in glfw.c at line 522
where there is a workaround precisely for kwin. Comment that out and see
if it solves your issue.
>
> And are you doing the following:
1. Open kitty, Ctrl-Alt-Enter 3 times to get 3 windows
ctrl+alt+enter doesnt launch kitty or open new kitty OS windows. Do you
mean 3 kitty instances or 3 OS windows in one kitty instance? The
shortcut for opening a new kitty OS window is ctrl+shift+n and a new
kitty window inside an existing kitty OS Window is ctrl+shift+enter
2. Click in bottom right window in kitty, type ls or something to display some text so selection is obvious.
Click means a single press and release or create a selection or what?
3. Move mouse to Firefox on second monitor, select some text. Release mouse
Move mouse to Firefox with the button held down or up? Is it neccessary
for Firefox to be on a second monitor or does it reproduce with just one
monitor?
… 4. Move mouse back to bottom right kitty window.
5. Click mouse.
6. Move mouse to top kitty window.
7. Click mouse.
8. Move mouse back to bottom right kitty window.
|
Fixed by removing that. |
While having multiple Kitty sessions/windows open (some with single sessions, some with multiple tabs—doesn't seem to matter) when moving the mouse across the screen, over inactive Kitty windows, it begins to select all text in relation to the mouse (as if I've pressed the mouse button down). The window remains inactive, but text is selected. I have to click/activate the windows to stop it _(depending on where/how the mouse is moving, it will sometimes scroll select until the mouse is moved completely out, or the window is activated and clicked to unselect.
Steps to reproduce the behavior:
ls, or anything that display text within the sessionsScreenshots
If applicable, add screenshots to help explain your problem.
Environment details
The text was updated successfully, but these errors were encountered: