Originally reported to TDF by Jim Greene via snail mail (thanks Jim!), and I can confirm. Steps: 1. Open a new Writer document, zoom it at about 310% 2. Open GNOME's Universal Access settings > Zoom options, turned it on with Magnification at e.g. 8× 3. Type text into Writer Result: Cursor and text spill off the bottom of the screen. Expected: Cursor and text always in views, roughly centred. No repro in 6.1, which doesn't use a Wayland window ("MetaWindowXwayland"): Version: 6.1.0.3 Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk2; Locale: en-AU (en_AU.UTF-8); Calc: group threaded Repro in 6.2, which uses a Wayland window ("MetaWindowWayland") Version: 6.2.0.3 Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded And recent trunk build: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d0dcd87788910e3c9f67a2b68534019c05b77bad CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Same issue in Calc. In impress, the view hardly follows the cursor, it is completely offset. Jim reports not having the same issue with Calligra Words, but my testing (version 3.1.0) shows it uses MetaWindowXwayland, so not surprised. Michael, any idea?
I think we can blame Wayland (and GNOME?) here, unfortunately. The issue affects other applications and has been reported in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4112 It makes sense as there are other issues related to Wayland being bad at reporting window positions (is that correct, Michael?). The offset depends on the position/size of the window, and therefore is less noticeable at lower zoom levels and when the window is maximised. To see that, move the window toward the bottom-right of the screen and notice the issue getting worse and worse. As a workaround, as long as Xwayland is supported on the OS, one can force a MetaWindowXwayland window for LibreOffice with e.g.: WAYLAND_DISPLAY= libreoffice7.6 Michael, can you confirm that this is unfortunately out of our hands?
I can reproduce this in a GNOME Wayland session on Debian testing. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c479944eb4f9f5a22c7b248185f22c86ea85d12a CPU threads: 12; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded > As a workaround, as long as Xwayland is supported on the OS, one can force a > MetaWindowXwayland window for LibreOffice with e.g.: > > WAYLAND_DISPLAY= libreoffice7.6 I confirm that using GDK_BACKEND=x11 to force the x11 Gtk backend makes it work. (In reply to Stéphane Guillou (stragu) from comment #0) > Steps: > 1. Open a new Writer document, zoom it at about 310% > 2. Open GNOME's Universal Access settings > Zoom options, turned it on with > Magnification at e.g. 8× > 3. Type text into Writer FWIW, step 1) can also be skipped, i.e. it's unrelated to the internal zoom factor in LO. (In reply to Stéphane Guillou (stragu) from comment #1) > I think we can blame Wayland (and GNOME?) here, unfortunately. > The issue affects other applications and has been reported in > https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4112 > It makes sense as there are other issues related to Wayland being bad at > reporting window positions (is that correct, Michael?). > > The offset depends on the position/size of the window, and therefore is less > noticeable at lower zoom levels and when the window is maximised. To see > that, move the window toward the bottom-right of the screen and notice the > issue getting worse and worse. > > > Michael, can you confirm that this is unfortunately out of our hands? It's true that global/desktop coordinates/positions are not supported on Wayland any more, i.e. GNOME Mmagnifier can no longer query the position on screen directly from the application via AT-SPI. However, GNOME magnifier has been adapted to query window-relative positions from the application and calculate the global coords from that, see bug 149952 comment 2, so I'd expect that this should work when both, 1) the application reports correct window-relative coords (implemented in the context of tdf#149952) 2) GNOME magnifier correctly calculates the screen coordinates and moves to these then (or similar, whatever the exact mechanism within GNOME magnifier does) This sounds like it could be a bug in either 1) or 2). Since this worked OK in a quick test with Gedit, the problem might be 1), i.e. LO's window-relative coords still not being fully accurate after the changes done in the context of tdf#149952, but that would need further examination. (I've also commented on https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4112 accordingly)
Created attachment 192177 [details] Screencast demonstrating one issue w/ AT-SPI coords reported by gtk3 LO
(In reply to Michael Weghorn from comment #2) > Since this worked OK in a quick test with Gedit, the problem might be 1), > i.e. LO's window-relative coords still not being fully accurate after the > changes done in the context of tdf#149952, but that would need further > examination. Indeed, something is going wrong there. attachment 192177 [details] demonstrates one issue: The relative position of the doc/paragraph is incorrect. The screencast demonstrates clicking through LO's a11y hierarchy in a modified version of Accerciser (s. comment below). When moving from the "panel" to its "root pane" child, the y position is too low: It includes the menu bar, but not the status bar. It should most likely be the other way around, since the menu bar is a native one. Actually, when disabling the menu bar (by switching to the Tabbed interface), the area highlighted by the modified Accerciser version is correct. Indeed, when retesting the use-case described here with the Tabbed interface, the typed text is visible, i.e. focus-tracking works (better). The text is still at the very bottom of the screen (while it is pretty much in the middle with Gedit), so there might be further aspects that need consideration. (This is with a local, modified test version of Accerciser that queries the window coords from KWin in a Plasma Wayland session, since Accerciser currently depends on desktop coords otherwise and wouldn't highlight the correct area at all.) I vaguely remember jmux mentioning in the past that there's some hack to support native menu bars that involves fiddling with the menubar height (and afc828b9833b7a612369e95606ba56d41ef2c369 looks related at a first glance, this was reverted later), maybe this is backfiring here? > (I've also commented on > https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4112 accordingly) That one was indeed closed as fixed now, referring to the GNOME magnifier commit I mentioned earlier.
When using the qt6 VCL plugin (with current dev branch of qtbase) in a GNOME Wayland session, the situation is a bit better, but the menu bar also seems to be an issue. With the menu bar enabled, the caret keeps being at the very bottom right edge of the screen. With the Tabbed interface, the cursor is more in the centre and further up, much closer to what it should be and generally usable from what I can say. Note however that focus handling only worked when I started the Orca screen reader before starting LO, since it seems that a11y is otherwise not enabled by default in Qt and the object:caret-changed events otherwise don't get sent to notify about the new cursor position.
There's a useful script to highlight the current caret position attached to https://bugreports.qt.io/browse/QTBUG-95725 . That works on X11 as is, but not on Wayland, since getting/setting window positions isn't easily possible any more...
Thank you for the analysis, Michael! Much appreciated. (In reply to Michael Weghorn from comment #4) > That one was indeed closed as fixed now, referring to the GNOME magnifier > commit I mentioned earlier. Does that mean that it is recommended to test this bug with GNOME 42.2 or above? https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/cb0c4bd1c2c19645e4cd1be9733c22e8747b07d8
(In reply to Stéphane Guillou (stragu) from comment #7) > Does that mean that it is recommended to test this bug with GNOME 42.2 or > above? > https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/ > cb0c4bd1c2c19645e4cd1be9733c22e8747b07d8 Yes, it is. (My tests on Debian testing were with Gnome 44, so the issues I mention are still relevant.)
(In reply to Michael Weghorn from comment #4) > Indeed, something is going wrong there. attachment 192177 [details] > demonstrates one issue: The relative position of the doc/paragraph is > incorrect. > The screencast demonstrates clicking through LO's a11y hierarchy in a > modified version of Accerciser (s. comment below). > When moving from the "panel" to its "root pane" child, the y position is too > low: It includes the menu bar, but not the status bar. It should most likely > be the other way around, since the menu bar is a native one. GTK 4 just got support for reporting the bounds of accessible non-widget objects: https://gitlab.gnome.org/GNOME/gtk/-/commit/f30c3d8133cf34401725482811e93bdd3853b96d When using the gtk4 VCL plugin with a current gtk main branch (as of commit e4ec066337722f89176642b1f564d52cdaa822e2), the issue described above when using Accerciser to go through the a11y hierarchy does not occur, but it does occur with gtk3. (GTK 4 is missing API for reporting text etc., though, so is not a solution at this point in time, but it might still be an interesting point of reference to compare to what happens there. a11y was completely redone from scratch there, though, so another approach than there might be needed.) Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ad4a06692b05c4312c1c7c8a8ff38cf12422e692 CPU threads: 12; OS: Linux 6.6; UI render: default; VCL: gtk4 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
On further analysis (and while upstreaming my Accerciser changes mentioned in comment 4 + extending them to work with GNOME/Mutter as well), I see a problem with gnome-shell/Magnifier not using the correct area on screen when using a native Wayland application while it works with the same app running on XWayland. I've reported an issue with a simple sample app there now: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7559 (This is separate from the incorrect position being reported by LO due to the menu bar with gtk3 or qt6, which is a LO issue.)
(In reply to Michael Weghorn from comment #10) > On further analysis (and while upstreaming my Accerciser changes mentioned > in comment 4 + extending them to work with GNOME/Mutter as well), I see a > problem with gnome-shell/Magnifier not using the correct area on screen when > using a native Wayland application while it works with the same app running > on XWayland. > > I've reported an issue with a simple sample app there now: > https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7559 > > (This is separate from the incorrect position being reported by LO due to > the menu bar with gtk3 or qt6, which is a LO issue.) Turns out that that a wrong understanding/testing on my end, not a Magnifier issue at all. -> needs to be analyzed on LO side