Oooookay, now this is getting thoroughly weird (on nightly from here).
If I have a file with numbers, they are completely reversed. for i in
seq 1 26 ; do echo $i >> num.txt ; done
Bildschirmaufzeichnung_vom_2022-12-09__14-18-05
Going back to the list of letters: if I just hold backspace, I am able to ctr+z
out of everything up to me having deleted the p
and the newline and then getting a utf-8 insertion error when trying ctrl+z
(which now doesn't work). So maybe something is misinterpreted as a unicode reversal???? So it must somehow depend on the content of the buffer/file.
Bildschirmaufzeichnung_vom_2022-12-09__14-22-00
Edit: So I guess the undo is always(?) in reverse order but happens to be halway correct when a p is in there???
It's not an X11 issue. The same happens on wayland. And I am also able to reproduce this on the nightly flatpak.
I'm using a current and up-to-date Fedora 37 release so everything should fit together. The PC is a bit slow though. So maybe we're race-conditioning some signals here.
I press and hold Shift+Ctrl+Backspace to rapidly delete lines.
I tapped fast. I just tried and it also happens when holding. So either should work to reproduce.
The list being restored in reversed order
Only bits of it though. I had a look at the fix of the files-issue a few days ago and I don't think they are related.
I'm currently in an X11 session. I'll try wayland later today. Don't know if that makes a difference.
I found this bug at least in gnome-text-editor 43.1: If you delete whole lines with Shift+Ctrl+Backspace in a fast manner and then press Ctrl+Z once to undo the changes, the lines are not restored in order. Here is a video:
Bildschirmaufzeichnung_vom_2022-12-09__13-05-23
I accidentally first opened this bug here: gedit#538
I found this bug at least in gedit 43.1: If you delete whole lines with Shift+Ctrl+Backspace in a fast manner and then press Ctrl+Z to undo the changes, the lines are not restored in order. Here is a video:
I'm sorry, this is not gedit but gnome text editor.
I found this bug at least in gedit 43.1: If you delete whole lines with Shift+Ctrl+Backspace in a fast manner and then press Ctrl+Z to undo the changes, the lines are not restored in order. Here is a video:
I really didn't know that it should matter, how the on-screen keyboard is activated. Are there more ways than the accessibility menu?
Everywhere the keyboard did appear, the issue was there. I wouldn't know how to check for XWayland windows. The onscreen keyboard didn't work at all in Chrome.
I've also attached a video where the issue is reproduced including the activation of the accessibility tool.
The on-screen keyboard always appears on the primary screen (which probably is wrong anyways, see #3011 - it's very hard to use the on-screen keyboard in a dual-head environment). If the cursor is at a place where the on-screen-keyboard would hide the cursor, the window is moved above the on-screen-keyboard. This occurs, even if the window with the input and the on-screen-keyboard are on different screens, such as the keyboard is not in fact hiding the cursor.
The window moves up, even though it's on a different screen than the on-screen-keyboard
Either the window doesn't move up or the keyboard should have opened on the correct screen in the first place. The latter would be the correct solution, as the on-screen-keyboard is barely usable for windows on the "wrong" screen. Very bad usability issue.
@aklapper You're right, sorry. I amended the original report.
Gedit prevents shutdown in gnome-shell when documents are unsaved. This is fine if the session is active.
If you use "change user" and are in the gdm login screen and use the shutdown-functionality there, shutdown just does not work and you get no info and no feedback. I assume (but not have tested it), that it also doesn't work when you login as another use and try to shut down.
I don't know what the best solution or behaviour for this is, but not being able to shut down the machine without any user feedback surely isn't it.
Version: Fedora 34/GNOME 40
Steps to reproduce:
Now the system does not shut down and the user gets no feedback on why this isn't.
I think this kinda relates to #146
It is really unclear how control characters are handled.
I am pretty sure that not allowing to enable "alway on top" for maximised windows is a feature, to not "hide" all other windows. But that you can't disable it for windows starting out as "always on top" is surely a bug, as it forces "hiding" all other windows.
This is inconsistent. You can't have it both ways.
Either you want a way to disable the entire desktop. Then you should allow enabling AoT for maximized windows. Or you don't want a way to disable the entire desktop, then AoT shoudl be disabled for maximized windows (or at least there should be a way to disable it).
Popovers are used in gnome when window titles are right-clicked for minimization, maximization, closing, etc.
When the right-click is dismissed with another right-click or left-click somewhere on the screen, the behaviour gets strange in that the next mouse event isn't handled correctly (maybe not GTK, please move then).
Bildschirmvideo_von_28.05.2021_19_16_44
In the video you see:
Now to a second strange behaviour that is related:
Bildschirmvideo_von_28.05.2021_19_25_49
Here you see me right-clicking the terminal window title, right-clicking (or left, doesn't matter) the terminal window to dismiss the popover, right-clicking the nautilus window shows the window title popover that shouldn't be there, and clicking minimize minimizes nautilus.
This might be a seperate issue, but the popover arrow doesn't get updated correctly between the window switches. Here you see me causing the popover behaviour in nautilus, dismissing the arrow-down popover with right-click, and right-clicking the terminal window border and we get the wrong arrow orientation:
Bildschirmvideo_von_28.05.2021_19_36_20
I'm running gnome 40.1.0 on a mostly up-to-date Fedora.
I kinda have an idea what's going on with the context menus at least. The context menu should be positioned on the left of the cursor if there is no space on the right. But once it would be basically halways on the other screen, it has space.
Maybe doesn't explain the hint and maybe doesn't explain the double context menu not being shown. But I think it has something to do with calculating whether there is enough space for the context menu.
Strange that the context menu doesn't even appear for #1214.
They do indeed look related. And they all relate to an imaginary border of about 10 to 20 pixels. Maybe the window shadow size?
Knowing what to look for, I think this is all the same issue. The context menu should open to the left of the cursor if there is no space to the right. And this does happen up to a point. Then the context menu pops up on the wrong screen.
Okay, now I am sure this is the same issue. Happens also when the window is not snapped, just close!
Bildschirmfoto_von_2021-05-28_13-24-55
So not just an off-by-one error.
The following might be related (and I would like a hint against which project I should open the bug) but if you have a double-context menu on the left screen then in certain positions the second context menu does not get rendered. Possibly because it's going on the wrong screen. Doesn't happen when the original window is on the right screen.
Bildschirmvideo_von_28.05.2021_13_16_33
Edit: Journalctl gives the following in this case
Mai 28 13:20:59 maweki-desktop gnome-shell[3446]: Buggy client caused popup to be placed outside of parent window
Mai 28 13:21:04 maweki-desktop nautilus[431992]: Tried to unmap the parent of a popup
@antoniof this is under wayland. I thought it was nautilus as the hint is on the other screen because the original window is close to the other screen. The hint itself should be about center of the left screen (you see that is position is okay, just not the screen).
So "nautilus" reports the wrong screen at some point (off-by-one Error with the position of the window edge?).
I'll try it under X11 when I relog next time.