Created attachment 171049 [details]
Libreoffice window main screen (scaling factor 100%)

Created attachment 171050 [details]
Libreoffice writer on screen 2 (scaling factor=175%)

Basically reproduced with two 1920x1080 screens on Plasma Wayland, with only the second one having scaling set to 175%.

I see the behavior shown in attachment 171050 [details] if the Writer window first opens on screen 1 (scaling 100 %) and I move it to screen 2 (scaling 175 %), then maximize it. However, when unmaximizing the window and maximizing it again, it looks OK and the whole area of the window is used.

This is on Debian testing with plasma-workspace-wayland 4:5.20.5-5, libqt5core5a:amd64 5.15.2+dfsg-5.

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: bcf0ed2f672646107b42cbe67e5c3c9d170bb33a
CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: kf5
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

(In reply to Michael Weghorn from comment #3)
> Basically reproduced with two 1920x1080 screens on Plasma Wayland, with only
> the second one having scaling set to 175%.

Identical situation.

> 
> I see the behavior shown in attachment 171050 [details] if the Writer window
> first opens on screen 1 (scaling 100 %) and I move it to screen 2 (scaling
> 175 %), then maximize it. However, when unmaximizing the window and
> maximizing it again, it looks OK and the whole area of the window is used.

Not for me (arch linux, quite vanilla). You're right, Unmaximize/maximize makes it better but I wouldn't say "ok". 

1. every time you change screen, you have to minimize and maximize. 

2. take a look at the menu bar. It is really inconsistent: on the screen with 100% scaling, it keeps showing the menu-bar 175% scaled.

(In reply to giors_00 from comment #4)
> > I see the behavior shown in attachment 171050 [details] if the Writer window
> > first opens on screen 1 (scaling 100 %) and I move it to screen 2 (scaling
> > 175 %), then maximize it. However, when unmaximizing the window and
> > maximizing it again, it looks OK and the whole area of the window is used.
> 
> Not for me (arch linux, quite vanilla). You're right, Unmaximize/maximize
> makes it better but I wouldn't say "ok". 
> 
> 1. every time you change screen, you have to minimize and maximize. 
> 
> 2. take a look at the menu bar. It is really inconsistent: on the screen
> with 100% scaling, it keeps showing the menu-bar 175% scaled.

You're right, "OK" was maybe too strong, what I meant was that the most obvious problem in the screenshot (that a large part of the area is completely unused) disappears, so this might give a hint on where to look once somebody wants to analyze further.

I have been trying switching between gtk3 and qt5 plugin and have to say that with gtk3 things are going better. No globalmenu nor menu, though...

*** Bug 147639 has been marked as a duplicate of this bug. ***

Created attachment 179388 [details]
Weston with two outputs, one scaled and LO kf5 running.

I've found that I can run Bullsyeye Weston in a two screen setup with one scaled window via weston.ini:

  [core]
  xwayland=true

  [output]
  name=X1
  mode=800x600
  scale=2

  [output]
  name=X2
  mode=1024x768

and 

  weston -c $PWD/weston.ini --output-count=2

This works for LO gtk3, but kf5 is broken, interestingly just on the non-scaled screen, the other looks almost correct. But for whatever reason the start center image is tiny on 200%. It looks like LO has cached the larger fonts and scaling when moving the window form 2x to non-scaling. gtk3 is also "interesting", because it changes the layout of the windows near the border and even resizes it. That's still when completely on one screen.

Maximizing the main LO window on the scaled screen crashes LO with just Qt stuff in the backtrace (and also crashes gtk3), but works for the non-scaled screen. A kate window is maximizable on both screens and moving it between both screens works fine, so the kf5 LO should be able to work correct; but kf5 has additional Wayland libs; not sure they must be used explicitly or not. I've tried to find a way to flush the graphics cache somehow from the screen change handler to no avail in the end.

Just some finishing comment for the moment. LO VCL has basically no internal representation to handle a changed DPI / scaling factor properly. OutputDevice has     mnDPIX, mnDPIY and mnDPIScalePercentage, but these are just updated when a window is destroyed. A crude workaround would probably be to destroy and restore a window when it is moved to a different screen with different scaling.

Fixing VCL and widgets at large to support proper scaling is a lot of work. Since Gtk just has non-fractional scaling, it's way of simply upscaling the 100% output works quite well; maybe we should switch to this kind of scaling too, for the time being, seeing also bug 146297...

Created attachment 179412 [details]
Screencast of with v3 of Gerrit patch https://gerrit.libreoffice.org/c/core/+/132650

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/881cfbf77567194f5016a961d1c3db869734d68b

tdf#141578 Qt handle QtFrame screen changes

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/76de12a19bd90c0ed0d7a6a85502d3dccdbeba4e

tdf#141578 Qt handle QtFrame screen changes

It will be available in 7.3.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

This patch just prevents the min/max hassle, so LO updates the client area of the window correctly. Scaling factor change is still not handled, so I removed the target entries from the whiteboard.

*** Bug 151218 has been marked as a duplicate of this bug. ***

Still repro in 7.4.2.3.

Created attachment 185387 [details]
KF5 Backend Screenshot

I just tried out different VCL backends using the following Libreoffice version (from Arch/ Manjaro package):

Version: 7.5.0.3 (X86_64) / LibreOffice Community
Build ID: 50(Build:3)
CPU threads: 6; OS: Linux 6.0; UI render: default; VCL: kf5 (cairo+wayland)
Locale: de-DE (de_DE.UTF-8); UI: en-US
7.5.0-1
Calc: CL threaded

I have a primary 4K screen (125% wayland scaling) and two secondary FHD screens with 100% scaling.
The screenshots are all from my primary 4K screen.

First with kf5 backend:

Created attachment 185388 [details]
QT5 Screenshot

Same problem with the QT5 backend

Created attachment 185390 [details]
QT6 Backend

With Qt6 it looks more or less as desired.
Interestingly, xeyes tells me, that this is in fact running in XWayland mode...?
Can i force it to somehow use the native Wayland?

Created attachment 185391 [details]
QT6 backend in Wayland mode

Sorry for the spam, but I don' think that i can edit messages here or attach multiple screenshots to one post.

I found the reason for the apparently "good" scaling with QT6.
I hadn't installed the qt6-wayland package, so Qt was using XWayland.
It also reported the following in the console:

> SAL_USE_VCLPLUGIN=qt6 lowriter                                                                                                                    
> qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""

After I installed the package, Libreoffice was started with Wayland support and the scaling was bad as with QT5 again.

*** Bug 147216 has been marked as a duplicate of this bug. ***

I am now using two 1920 x 1080 screens, with the primary one at scaling 1.0, the secondary one at scaling 2.0, and legacy X11 app scaled by the system.

If the LibreOffice window is on the primary screen, the UI is oversized to be twice the normal size, but if it is moved onto the secondary screen, the UI is correctly sized.

*** Bug 157327 has been marked as a duplicate of this bug. ***

Is the issue related to fractional scaling only? I.e. does integer scaling (i.e. 200%) work correctly?

(In reply to Callegar from comment #23)
> Is the issue related to fractional scaling only? I.e. does integer scaling
> (i.e. 200%) work correctly?

I think what matters here are different scaling factors are used for different screens in a multi screen setup, independent of what the exact scaling factor is, i.e. it would be the same issue with 200%, but I don't have access to a second screen at the moment.

I agree, that the problem is the different scaling factor. I also checked it with 200% on 3k screen and 100% on FHD screen and the problem persists.

> Is the issue related to fractional scaling only? I.e. does integer scaling (i.e. 200%) work correctly?

My use case is reasonably typical. An inbuilt laptop screen running at 1920x1080 and an external monitor at 3840x2160.

In my testing, LibreOffice fails to scale correctly on the external monitor when the laptop monitor has no scaling applied (100%) and the external monitor is scaled at any level fractional or integer above 100% (e.g. 120%, 150%, 200%).

However, if I apply any scaling >100% to the laptop monitor (e.g. 105%), LibreOffice scales correctly on both screens.

Interesting, that is quite the opposite of what I experience. In my use case (3k monitor notebook screen, FHD external monitor), the external screen is the primary screen. Maybe the problem arises only when the external screen is scaled?
@Tim: can you check which screen is set as primary at your use-case?

When connected, I have my external monitor set to primary.

(In reply to Gergely HORVÁTH from comment #27)
> Interesting, that is quite the opposite of what I experience. In my use case
> (3k monitor notebook screen, FHD external monitor), the external screen is
> the primary screen. Maybe the problem arises only when the external screen
> is scaled?
> @Tim: can you check which screen is set as primary at your use-case?

My setup is similar to yours 3k laptop screen, 1650x1050 external monitor set to primary display when attached. 150% zoom on laptop screen, 100% on external monitor. LibO is usable on laptop screen when no monitor is attached, usable on laptop screen when external monitor is attached but not usable on external monitor (everything is scaled up way to much).

Unfortunately it may not be possible to use the GTK4 vcl as a workaround, because of bug 157452.

As a workaround for this issue, you can try using libreoffice with X11 as

WAYLAND_DISPLAY= libreoffice

because this is a wayland specific bug.

*** Bug 150677 has been marked as a duplicate of this bug. ***

*** Bug 157381 has been marked as a duplicate of this bug. ***

I uploaded a patch for Qt6/Wayland: https://gerrit.libreoffice.org/c/core/+/157683. It is far from perfect, but it seems to be an improvement for me. Someone who can test it?

Created attachment 190104 [details]
Screenshot with https://gerrit.libreoffice.org/c/core/+/157683 v4 in place

(In reply to Luca Carlon from comment #33)
> I uploaded a patch for Qt6/Wayland:
> https://gerrit.libreoffice.org/c/core/+/157683. It is far from perfect, but
> it seems to be an improvement for me. Someone who can test it?

Thanks! I've commented there.

Given that LibO + kf5 has also other issues with Wayland (e.g. wrong cursors, bug 141828), as a quick hack for those affected, consider temporarily aliasing libreoffice to `WAYLAND_DISPLAY= libreoffice` so forcing X11 (XWayland) mode.

(In reply to Callegar from comment #36)
> Given that LibO + kf5 has also other issues with Wayland (e.g. wrong
> cursors, bug 141828), as a quick hack for those affected, consider
> temporarily aliasing libreoffice to `WAYLAND_DISPLAY= libreoffice` so
> forcing X11 (XWayland) mode.

Sure, forcing to run on XWayland via this env var or QT_QPA_PLATFORM=xcb is a valid workaround for Wayland-specific problems. But does this actually help with the problem described here?
(I'd be surprised if the windows running on XWayland would behave better than the native Wayland ones. My understanding so far was that this bug here is only Wayland-specific because mixed scaling isn't supported on X11 at all, but I haven't explicitly tried yet.)

> other issues with Wayland (e.g. wrong cursors, bug 141828)

FWIW, that went unnoticed because it hadn't been added to the kf5 meta bug 102495. (It's not Wayland specific either though, the same on X11, fix pending in Gerrit now, s. bug 141828 for details).

> Sure, forcing to run on XWayland via this env var or QT_QPA_PLATFORM=xcb is a valid workaround for Wayland-specific problems. But does this actually help with the problem described here?

Here it seems to help, possibly because the compositor is set to make XWayland applications deal with the scaling themselves. Similarly it helps to use the GTK4 VCL, and I would have pointed the affected users to do that if it wasn't for other issues that I am experiencing with that.

While it is easy to work around this issue when invoking LibO from the shell or a desktop icon (it is enough to have a "regular" launcher and one forcing either the GTK3 VCL or the xcb mode), the thing becomes really problematic when you open links for office documents or email attachments via mime configured actions. In this case, unless you change all the file associations, LibO might end up starting with a wrong scaling.

Because this really breaks user experience, would be extra good if it could be fixed not just for Qt6, but also for Qt5 and Kf5. Will be probably another 3-4 months before plasma 6 premieres and one or more years before the more conservative distros pick it up. I have noticed mention of a work-in-progress patch for Qt6, is it backportable to Qt5?

(In reply to Callegar from comment #38)
> Here it seems to help, possibly because the compositor is set to make
> XWayland applications deal with the scaling themselves. Similarly it helps
> to use the GTK4 VCL, and I would have pointed the affected users to do that
> if it wasn't for other issues that I am experiencing with that.

Thanks for the clarification!

(In reply to Callegar from comment #39)
> While it is easy to work around this issue when invoking LibO from the shell
> or a desktop icon (it is enough to have a "regular" launcher and one forcing
> either the GTK3 VCL or the xcb mode), the thing becomes really problematic
> when you open links for office documents or email attachments via mime
> configured actions. In this case, unless you change all the file
> associations, LibO might end up starting with a wrong scaling.

If you permanently want to force a specific VCL plugin, adding `export SAL_USE_VCLPLUGIN=<your_preferred_plugin_name>` to `~/.bashrc` (or `~/.bash_aliases` if that's sourced by the former) should work. Or alternatively, you can also uninstall the package for the kf5 VCL plugin (e.g. libreoffice-kf5 for Debian).

> Because this really breaks user experience, would be extra good if it could
> be fixed not just for Qt6, but also for Qt5 and Kf5. Will be probably
> another 3-4 months before plasma 6 premieres and one or more years before
> the more conservative distros pick it up. I have noticed mention of a
> work-in-progress patch for Qt6, is it backportable to Qt5?

That depends on the change. The one mentioned in comment 33 would apply for qt5/kf5 as well, but it can't be merged as is, since it breaks other things.

Can confirm.

My situation:
- KDE Plasma, Wayland, LO 7.5 
- build-in 4K monitor, set to 200% scaling
- external FullHD monitor, set to 100% scaling

Dragging a LO app to built-in monitor: works correctly.
Dragging a LO app to external monitor: unusable (everything is huge)
Important obsevation: Setting external Monitor to 105%: works on both screens as configured, but 105% looks super-blurry (not LO-specific, everything looks blurry then).

Problem seems to be if at least one screen is set to exactly 100% and the others are set to any scaling not-100%, then the 100%-screen seems to take the scaling from another screen.

Update: using QT_QPA_PLATFORM=xcb makes it work for me, but is of course still a nasty hack which can not be expected by a regular end-user.

I installed LO 24.02, downloaded from the site of the Document Foundation, as second version on my Neon Unstable computer.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 6.0.80
KDE Frameworks Version: 5.249.0
Qt Version: 6.6.1
Kernel Version: 6.5.0-14-generic (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-6300U CPU @ 2.40GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 520
Manufacturer: Dell Inc.
Product Name: Latitude 5480

I started the program and it still looks ugly.
Then I started the program using SAL_USE_VCLPLUGIN=gtk3 ./soffice and LO looks 100% perfect. 
I also started the program with QT_QPA_PLATFORM=xcb ./soffice and that looks better than just stating the program with ./soffice, but not perfect at all.

Might be a good idea to default to gtk3 even on KDE, at least temporarily.

(In reply to Callegar from comment #44)
> Might be a good idea to default to gtk3 even on KDE, at least temporarily.

My personal take is that the issue discussed here should not be reason enough for such a drastic step because:

* It only affects specific setups (dual-screen with different scale factors)
* The LO window is displayed properly on one of the screens at least, so moving the window to that screen should be a functioning workaround.
* People have explicitly asked for the Qt-based VCL plugin for Qt-based desktops in the past.
* No longer defaulting to kf5 on KDE Plasma 5 (and kf5 on Plasma 6) also brings the risk to have other bugs go unnoticed that could/should be addressed.
* Users for whom this is a critical issue can still switch to gtk3, either by setting SAL_USE_VCLPLUGIN=gtk3 or uninstalling the package containing the kf5 VCL plugin.

Distros or desktop environments can of course use one of their mechanisms to provide a different default behavior (e.g. config package, package dependencies, setting env variables,...).

All your points are indeed valid. As a matter of fact, I used a conditional precisely because cons might outweight pros, but I thing that an evaluation thereof can be useful.

- On one hand:

for anyone even a bit knowledgeable it should be quite easy to set env variables to have the preferred VCL as a default on their own machine. Most distros ease that by per-arranging a config file for that (e.g., in arch you get a pre-filled `/etc/profile.d/libreoffice-fresh.sh` where you just need to uncomment a line).

- On the other hand:

1. many, many laptop now have a 3k or 4k resolution and even 2k laptops benefit from a 1.25 scaling factor when they have 10.2", 11" or even 12" screens. Whenever these laptops get docked, you'll likely run into the issue. Most people who use laptops professionally dock them as soon as they have the possibility to do so, for ergonomics, productivity and - may seem weird - saving the laptop surface from getting stained on the palms zone. The setup is specific, but by no means rare. 

2. The issue is not serious in itself, but is extremely visible as something that "explodes in your face" as soon as you start the application. Very bad on a marketing perspective, IMHO.

3. the workaround for the issue is easy but definitely not easily discoverable. Having a "tip" for it might be useful, but from a marketing perspective it is bad to have tips about known issues.

4.  Most users do not even know what a VCL is. Users asking for QT VCLs probably represent the subset of users knowledgeable enough to set the SAL_VCL_PLUGIN env variable.

5. I may be wrong, but I am getting the impression that either: the issue is not easily fixable or the developers working on the QT VCL have more urgent tasks at this time (QT6, probably), so the issue is to stay for some time. During this time, point 1. can only get worse.

6. Applications that work well out of the box on gnome, but not on KDE may unfortunately cast a bad shade on the whole of KDE.

Personally, I do not care that much, since I am among the user-set knowing `SAL_VCL_PLUGIN`, but I wonder about the less knowledgeable group.

SAL_USE_VCLPLUGIN=gtk3 is not even an option in my case, since global menu won't work...
I do not know if it is due to another bug in libreoffice, but the result is here: none of the available VCLs work when you use KDE with global menus and different scale factors on 2 screens.

Also, the other workaround, consisting in moving libreoffice to a different screen does not work in my case, since my main screen is the one on which scale is faulty.

Maybe I am the only unlucky guy on Earth whose configuration makes all workarounds ineffective. I don't know. But it really sucks when you are in this case.

(In reply to Callegar from comment #46)
> All your points are indeed valid. As a matter of fact, I used a conditional
> precisely because cons might outweight pros, but I thing that an evaluation
> thereof can be useful.
> (...)

I agree it makes sense to weigh pros and cons, thanks for your considerate thoughts, that's much appreciated.

> 4.  Most users do not even know what a VCL is. Users asking for QT VCLs
> probably represent the subset of users knowledgeable enough to set the
> SAL_VCL_PLUGIN env variable.

True. But I tend to think that those using Plasma on Wayland currently generally are the more technically-oriented users that are more likely to find necessary information and more likely prepared to encounter some "challenges".
(I'm personally trying Plasma on Wayland every few months and so far, I always switched back to X11 for my production work since I ran into issues. It's getting better every time, though, and with Plasma 6, Wayland will be the default, so that's going to change in the mid/longer run apparently.)


> 5. I may be wrong, but I am getting the impression that either: the issue is
> not easily fixable (...)

From how I understand it (reading Jan-Marek's earlier comments), it's indeed not easily fixable and requires not only work on the Qt VCL plugin, but also down deep in the central rendering code, which makes it time-consuming and also potentially risky to break other things and thus needs extra care. Of course, it might be possible that there's an easier approach that nobody came up with yet...

> (...) or the developers working on the QT VCL have more urgent
> tasks at this time (QT6, probably), so the issue is to stay for some time.

I cannot speak for all people who might potentially want to contribute (new contributors welcome!) but at least for me, Qt-based VCL plugins are indeed something I have limited time available for, so I'm mostly focusing on things that seem either fairly straightforward to implement or particularly critical.

(In reply to aldo-public@laposte.net from comment #47)
> SAL_USE_VCLPLUGIN=gtk3 is not even an option in my case, since global menu
> won't work...
> I do not know if it is due to another bug in libreoffice, but the result is
> here: none of the available VCLs work when you use KDE with global menus and
> different scale factors on 2 screens.
> 
> Also, the other workaround, consisting in moving libreoffice to a different
> screen does not work in my case, since my main screen is the one on which
> scale is faulty.

What should work is forcing a particular scale factor using the QT_SCALE_FACTOR environment variable, e.g. QT_SCALE_FACTOR=1.5 if your main screen uses 150% display scaling.

(In reply to Michael Weghorn from comment #48)
> > 5. I may be wrong, but I am getting the impression that either: the issue is
> > not easily fixable (...)
> 
> From how I understand it (reading Jan-Marek's earlier comments), it's indeed
> not easily fixable and requires not only work on the Qt VCL plugin, but also
> down deep in the central rendering code, which makes it time-consuming and
> also potentially risky to break other things and thus needs extra care. Of
> course, it might be possible that there's an easier approach that nobody
> came up with yet...

One aspect to mention here:
There's currently an Outreachy project to implement Qt welding (see bug 130857), i.e. using native Qt widgets and letting Qt handle the rendering. For those widgets that are converted to this approach, I'd expect that the use case described here should "just work" in general.

I've just tried one of the simple message dialogs that were converted to the new approach in 

commit 1ace888823443b85d4a81b94656844f1b27e2987
Author: OmkarAcharekar
Date:   Wed Dec 20 19:13:50 2023 +0530

    tdf#130857 Use native qt widgets - simple message dialog

and that indeed works fine when moving the dialog between the 2 screens using different scale factors.
Whether implementing all of the existing weld API for Qt will by itself be sufficient is something I'm unsure of yet, though.
(But if gtk3 works fine, that might be related to it using native Gtk widgets already for most of the UI.)

Setting priority to "high" because we have 6 duplicates.

Still present in LO 24.2.1.2 running on Plasma 5.27.8.

After trying all the different combinations of WAYLAND_DISPLAY and SAL_USE_VCLPLUGIN, the one that works the best for me is (uses XWayland):

WAYLAND_DISPLAY= SAL_USE_VCLPLUGIN=kf5 /usr/bin/libreoffice

The workaround that works fine for me at this time is to put an executable script under e.g. ~/.local/bin called "libreoffice" containing:

#!/bin/bash
WAYLAND_DISPLAY= SAL_USE_VCLPLUGIN=kf5 /usr/bin/libreoffice "$@"

Make sure that this location (~/.local/bin) is in your PATH. If the .desktop files used to start the libreoffice programs call e.g. "localc" rather than "libreoffice --calc", then you also need "localc" etc. scripts (in order to be able to start libreoffice programs from the GUI). If the .desktop files in your distro use an absolute path for the executable, then you need to override those.

Came here to report a similar issue. I am using 2 monitors with different DPI/scalings (100% and 150%) and Arch Linux. There was no scaling issue under Wayland Gnome fractional scaling. Now that I switched to KDE Plasma 6, there is a weird scaling issue. On the 100% DPI monitor, LibreOffice is correctly displayed; but if I move the window to the 150% DPI monitor, the window content becomes really small. But if I disable the 100% monitor, then LO starts and appears in the correct scaling on the 150% monitor. So, it's not that LO is incapable of scaling, but I think there's some bug to determine the correct scaling value to use.

(In reply to typingcat from comment #55)
> Came here to report a similar issue. I am using 2 monitors with different
> DPI/scalings (100% and 150%) and Arch Linux. There was no scaling issue
> under Wayland Gnome fractional scaling. Now that I switched to KDE Plasma 6,
> there is a weird scaling issue. On the 100% DPI monitor, LibreOffice is
> correctly displayed; but if I move the window to the 150% DPI monitor, the
> window content becomes really small. But if I disable the 100% monitor, then
> LO starts and appears in the correct scaling on the 150% monitor. So, it's
> not that LO is incapable of scaling, but I think there's some bug to
> determine the correct scaling value to use.

Likely the so-called gtk3 VCL plugin was used on GNOME (which is the default there) and now the kf5 or kf6 one is used.

Does setting the environment variable SAL_USE_VCPLUGIN=gtk3 before starting LO bring back the previous behavior? (Please also double-check that "Help" -> "About LibreOffice" says "VCL: gtk3" then.)

Thanks @Martin for you hint.
The combination

> WAYLAND_DISPLAY= SAL_USE_VCLPLUGIN=kf5 /usr/bin/libreoffice 

also shows good results on my end.
Even tho I would prefer a native Wayland window with correct scaling, this is good enough for now.
Also the kf6 VCL plugin seems to work for me.

I am using:
Operating System: Manjaro Linux 
KDE Plasma Version: 5.27.11
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.12
Kernel Version: 6.6.24-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 6 × Intel® Core™ i5-8600K CPU @ 3.60GHz
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 6800
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7B46
System Version: 1.0