https://bugs.documentfoundation.org/show_bug.cgi?id=139913
--- Comment #21 from Jan-Marek Glogowski <glo...@fbihome.de> ---
Interesting findings, indeed.
Please post the output from xrandr, but without all the mode lines, like:
> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
> eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y
> axis) 344mm x 194mm
> ...
So we can see, how X sees all the monitors mapped internally.
My current guess: on resize outside the top-left monitor, some of the VCL
abstraction reports the wrong position of the window - maybe some
https://doc.qt.io/qt-5/qwidget.html#mapToGlobal is missing. So VCL thinks the
window top-left still is on A monitor, while you click at the same relative
poisition on the other monitors. And then Calc scrolls and select the range;
guess the selected range is actually the size of a monitor in pixel. Internally
that position and size is cached in SalFrameGeometry, so once you trigger this,
things break eventually. Or the selection code queries the Window position and
gets the wrong result.
But that should also happen with two monitors, always... or it still might be a
Qt bug in Kubuntu. Everything looks, like we should have a very prominent bug
with a lot of reports. Or it's some timing problem somewhere. Sill puzzling.
Q: do you have any input method (IM) enabled, like fcitx or ibus?
Just because I just got bug 140207, which is unrelated to yours. But I never
tested IM with multiple monitors.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
