Created attachment 169141 [details]
Video of what is going on

Here is screen capture with the issue clearly visible

no repro in

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 8c9341120c922ca5eadf64756ea858a84563ee51
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL

Possibly a KDE with HiDPI problem?

Please attach the info from About -> LibreOffice.

* Does this also happen, if you start LO with "SAL_USE_VCLPLUGIN=gen soffice --calc"?
* What do you mean by "clicking into any single cell"? A single click to select it, or double click to edit?

I've set the bug to NEEDINFO. When you provide the info, please reset it to UNCONFIRMED.

(In reply to michnovka from comment #0)
> Additional Info:
> I have 4x4k monitors, but I dont think this is related as it only happens
> when I actually resize, not when I move between monitors only without
> resizing.

Also, can you try whether this still happens with just 1 monitor connected?

Is this an X11 or a Wayland session? (You can check e.g. by running the command "echo $XDG_SESSION_TYPE" in a terminal.)

* Does this also happen, if you start LO with "SAL_USE_VCLPLUGIN=gen soffice --calc"?

NO, it works without issues when launched this way.

* What do you mean by "clicking into any single cell"? A single click to select it, or double click to edit?

I mean when I click into cell. to select it, not to edit it. As soon as click is pressed, it selects the multiple cells, so it is actually impossible to edit with a double click

* Is this an X11 or a Wayland session? (You can check e.g. by running the command "echo $XDG_SESSION_TYPE" in a terminal.)

I use X11 session

I can't reproduce if I set QT_SCALE_FACTOR=2 (to somewhat "simulate HiDPI") either.

What does 'env | grep QT' print for you?

Is the behaviour the same if you use the qt5 instead of kf5 VCL plugin, i.e. start LibreOffice like this: "SAL_USE_VCLPLUGIN=qt5 soffice --calc"

It's not clear this is actually some kf5 problem, because that info is still missing (I know it's Kubuntu, but still...):

(In reply to Jan-Marek Glogowski from comment #3)
> Please attach the info from About -> LibreOffice.

(In reply to Michael Weghorn from comment #6)
 > Is the behaviour the same if you use the qt5 instead of kf5 VCL plugin, i.e.
> start LibreOffice like this: "SAL_USE_VCLPLUGIN=qt5 soffice --calc"

qt5 shares mouse and keyboard code with kf5, so I would be surprised, if that results in a difference.

> (In reply to Jan-Marek Glogowski from comment #3)
> > Please attach the info from About -> LibreOffice.

Ok it's actually "Help -> About LibreOffice"...

About LibreOffice:

Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: kf5
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 1:7.0.4~rc2-0ubuntu0.20.04.2
Calc: threaded

-----

when I start with "SAL_USE_VCLPLUGIN=qt5 soffice --calc" then the bug is present.

superuser@TheTower:~$ env | grep QT
QT_ACCESSIBILITY=1
QT_SCREEN_SCALE_FACTORS=DP-0=2;DP-1=2;DP-2=2;DP-3=2;DP-4=2;DP-5=2;DP-6=2;DP-7=2;
QT_AUTO_SCREEN_SCALE_FACTOR=0

The only idea I can come up with right now is this remaining question:

(In reply to Michael Weghorn from comment #4)
> Also, can you try whether this still happens with just 1 monitor connected?

and explicitly setting QT_SCALE_FACTOR=1 in addition (in order to disable scaling) to see whether any of those aspects are related. Does the issue still happen then?

Hi, I was unable to reproduce the issue with single monitor attached.

I will test disabling QT scaling with multiple monitors once I set everything back up.

QT scaling has no effect on the issue. It is present regardless of the value

(In reply to michnovka from comment #12)
> Hi, I was unable to reproduce the issue with single monitor attached.

Thanks! That gets us a bit further. Can you check whether you can reproduce with 2 or 3 screens?

What is the exact resolution of the screens and how are they (virtually) arranged, e.g. are those 4 screens with resolution 3840x2160 "next to each other", resulting in a total virtual screen size of 15360x2160?

Does it play any role on which of the screens the LibreOffice window is located (e.g. it doesn't happen when positioned on the most left-hand screen, but does when positioned when on the most right-hand one)?

(Side note: One idea to try to reproduce this without having the actual hardware might be to try setting up a VM with corresponding virtual screens, not sure whether that will work properly.)

Hi,

I can reproduce with 3 screens, didnt reproduce with 2, but its really random sometimes. Its not 100% reproducible even with 4 monitors.

My 4 monitors are in a square, so the total canvas is 7680 x 4320.

It happens regardless of where I have the libreoffice window, it seems to happen once I resize the window after opening it. If I just open calc and leave it as is (even moving it between monitors) the issue does not occur. As soon as I resize it even 1 px, and even if I then resize it back, I have the bug present.

(In reply to michnovka from comment #15)
> I can reproduce with 3 screens, didn't reproduce with 2, but its really
> random sometimes. Its not 100% reproducible even with 4 monitors.

Yeah - that's actually something I would expect, because a two monitor setup is quite common (AKA laptop + additional output) and we would be spammed with bug reports, if that would be broken in general on resize. Not that this helps solving the mystery. There is no code, like "if monitors > 2".

I just watched the video again. So it looks like it always selects the correct cell, but then scrolls somewhere else. So it's more like a normal selection while holding the left button and then moving the mouse.

So some more questions, because I don't have a HW setup to reproduce the problem:

* If this bug happened, does the rest of the Calc window still work correct? Like the menu or toolbar button tooltips on mouse-over? 

* Can you try, if "soffice -env:UserInstallation=file:///tmp/test" magically works? Nothing indicates a corrupted user profile problem, but just to rule something else out.

* While writing this, I had an other idea: normally people arrange two monitors horizontally. What happens, if you arrange them vertically instead? Because you have the 4 monitors arranged as a square, that is some uncommon setup.

Created attachment 169651 [details]
Additional behavior example in text input field

There are random behavior issues in other parts of calc aside from the cells only. E.g. see this video attachment of what happens when I click in the middle of the address bar. I am just performing SINGLE clicks.

Its as if I had the onmousedown event triggered already prior to making the click, and it results in text being selected instead of cursor being placed where I click.

OK a breakthrough in investigation!

I have my monitors like this:

A B
C D

and what I noticed is:

1. when in monitor A, everything works fine

2. when in monitor B, I click cell and it selects a LINE (single row, N columns)

3. when in monitor C, I click cell and it selects a COLUMN (single column, N rows)

4. when in monitor D, I click cell and it selects AREA (N columns and N rows).

In all cases the selected area starts in the cell I click.

Furthermore:

- the behavior happens when I move resize the window in given monitor.

- when the bug is present in monitor X, and I move the window to another monitor (without resizing), then clicking on any cell does NOTHING. As soon as I resize it by even 1 pixel, the behavior happens as described in the above section.

P.S. same bug even with /tmp/test userprofile

Further investigations:

I can fix the behavior by moving calc window into monitor A and resizing it. If I then move the window to any other monitor, it works just fine, until I resize it. Then its screwed up as desribed above

If I make the bug appear (in monitors B,C or D) and move the calc window without resizing to any other monitor (including A), the cells are unclickable in other monitor (apart from the one where the bug was caused. That one works with the bug present when the window is moved back into it)

If I take the window to be across multiple monitors, the bug appears according to the criteria described above BASED ON WHICH MONITOR THE CURSOR IS WHEN I RESIZE THE WINDOW. When the bug occurs (e.g. I move window to span across A and B, then resize it a bit in B, so a LINE is selected), then only the cells are clickable only in monitor B, when I click in A, nothing happens whatsoever.

So this is totally depending on multiple monitors.

Let me know how else I can help.

Nice findings!

Can you try whether it's still reproducible if you reduce the screen resolution for all 4 screen?

(In reply to Michael Weghorn from comment #14)
> (Side note: One idea to try to reproduce this without having the actual
> hardware might be to try setting up a VM with corresponding virtual screens,
> not sure whether that will work properly.)

I just tried that and can set up multiple screens or can even set up a single virtual HiDPI screen using libvirt/virt-manager and spice-vdagent (but need to disable/remove kscreen which somehow gets in the way), but I'm unable to set up several virtual HiDPI screens at the same time. xrandr fails setting the corresponding resolution, might be memory-related or something different (and screen just turns black if I further increase memory for the virtual graphics card).

I couldn't quickly reproduce the issue with 4 virtual screens with a 1024x768 resolution, but the approach might be worth trying again in case you say it even works with a minimum resolution of XxY on all 4 screens...

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.

> Can you try whether it's still reproducible if you reduce the screen resolution for all 4 screen?

I am sorry, but when I tried this last time, I got totally screwed up KDE Plasma layout which took over 4 hours to fix. I may try this later, but currently am busy with work and cannot afford to risk messing up my main workstation like that.

xrandr output:

Screen 0: minimum 8 x 8, current 7680 x 4320, maximum 16384 x 16384
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
DP-4 connected primary 3840x2160+3840+0 (normal left inverted right x axis y axis) 527mm x 296mm
DP-5 connected 3840x2160+3840+2160 (normal left inverted right x axis y axis) 527mm x 296mm
DP-6 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 527mm x 296mm
DP-7 connected 3840x2160+0+2160 (normal left inverted right x axis y axis) 527mm x 296mm

> Q: do you have any input method (IM) enabled, like fcitx or ibus?

Honestly, no idea, how do I verify this? I have standard Kubuntu installation, I use 200% scaling and nVidia GPU.

(In reply to michnovka from comment #22)
> xrandr output:

...

Nothing unexpected here.

> > Q: do you have any input method (IM) enabled, like fcitx or ibus?
> 
> Honestly, no idea, how do I verify this? I have standard Kubuntu
> installation, I use 200% scaling and nVidia GPU.

Then you probably don't have them, because you have to explicitly activate an configure them for complex input languages, like Chinese. Probably a simple package query for 

$ dpkg -l "ibus*" "fcitx*"

will return nothing on your system.

BTW: the "text input" video looks the same then the cell selection problem.

(In reply to Jan-Marek Glogowski from comment #23)
> (In reply to michnovka from comment #22)
> 
> $ dpkg -l "ibus*" "fcitx*"
> 
> will return nothing on your system.


superuser@TheTower:~$ dpkg -l "ibus*" "fcitx*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name              Version           Architecture Description
+++-=================-=================-============-==================================
un  fcitx-data        <none>            <none>       (no description available)
rc  ibus              1.5.22-2ubuntu2.1 amd64        Intelligent Input Bus - core
un  ibus-anthy        <none>            <none>       (no description available)
un  ibus-clutter      <none>            <none>       (no description available)
ii  ibus-data         1.5.22-2ubuntu2.1 all          Intelligent Input Bus - data files
un  ibus-doc          <none>            <none>       (no description available)
un  ibus-el           <none>            <none>       (no description available)
un  ibus-googlepinyin <none>            <none>       (no description available)
un  ibus-gtk          <none>            <none>       (no description available)
un  ibus-gtk3         <none>            <none>       (no description available)

(In reply to michnovka from comment #24)
> (In reply to Jan-Marek Glogowski from comment #23)
> > (In reply to michnovka from comment #22)
> > 
> > $ dpkg -l "ibus*" "fcitx*"
> > 
> > will return nothing on your system.
> 
> 
> superuser@TheTower:~$ dpkg -l "ibus*" "fcitx*"
> Desired=Unknown/Install/Remove/Purge/Hold
> |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name              Version           Architecture Description
> +++-=================-=================-============-
> ==================================
> un  fcitx-data        <none>            <none>       (no description
> available)
> rc  ibus              1.5.22-2ubuntu2.1 amd64        Intelligent Input Bus -
> core
> un  ibus-anthy        <none>            <none>       (no description
> available)
> un  ibus-clutter      <none>            <none>       (no description
> available)
> ii  ibus-data         1.5.22-2ubuntu2.1 all          Intelligent Input Bus -
> data files
> un  ibus-doc          <none>            <none>       (no description
> available)
> un  ibus-el           <none>            <none>       (no description
> available)
> un  ibus-googlepinyin <none>            <none>       (no description
> available)
> un  ibus-gtk          <none>            <none>       (no description
> available)
> un  ibus-gtk3         <none>            <none>       (no description
> available)

Ok - nothing, as in no installed packages (except for ibus-data, which doesn't do anything without ibus)

I'm running out of ideas...

Today I found out that even Writer has random issues in other monitor screens than the top left one.

I cannot select text properly, when I try to slide padding bar on the ruler, I am not able to do so.

I have no other apps on my Kubuntu PC behaving this way, they all work regardless of which window I open them in.

I updated to 7.1.1.2 and the issues are exactly the same.

I repeat that all libre office apps are absolutely usable and without any issues once I move them to the top left monitor, but any other than that and I cannot work, as clicks are not registered or registered as some weird click + drag.

Hi, the bug happens still with 7.2.3. Basically when I have the monitors arranged like:

1 | 2
-----
3 | 4

When I have windows in monitor 1, I can move them, resize them, whatever, no issues.

When I take window from monitor 1, and move it to 2,3,4 WITHOUT resizing, it works without issues as well.

As soon as I resize or maximize the window in monitors 2,3,4, I get the weird behavior where in Calc:
 - in monitor 2 it selects like 40-70 cells in one row (the row of cell I clicked on)
 - in monitor 3 it selects like 40-70 cells in one column (the column of cell I clicked on)
 - in monitor 4 it selects area of 40-70x40-70 cells starting from the cell which I clicked on

Further observations:

Moving the window between monitors AFTER I did a resize which resulted in bug behavior results in none of the cells being clickable. In fact none of the buttons or menu or anything is clickable. The only way to fix this is to resize the window or maximize it. It then takes on the bahavior described above, meaning the only way to fix it is to move window into monitor 1 and resize it.

Any ideas please?

so I was dealing with https://bugs.documentfoundation.org/show_bug.cgi?id=147290 and I ended up doing apt purge of libreoffice. Then reinstalled. Suddenly, all icons are a bit bigger than I was used to. I think this is what they are supposed to be though. They are blurry, but who knows, looks about right when it comes to size. And as a side effect, I now got rid of the weird issue with selection not working.

So while I cannot help to figure out what was causing it, I am 99% sure this was related to scaling somehow.

Feel free to close this bug.

(In reply to michnovka from comment #28)
> so I was dealing with
> https://bugs.documentfoundation.org/show_bug.cgi?id=147290 and I ended up
> doing apt purge of libreoffice. Then reinstalled. Suddenly, all icons are a
> bit bigger than I was used to. I think this is what they are supposed to be
> though. They are blurry, but who knows, looks about right when it comes to
> size. And as a side effect, I now got rid of the weird issue with selection
> not working.

Per default, scaled icons are based on PNG, because some people think the LO SVG renderer isn't god enough for icons. See bug 115439. Select an SVG icon set in Options -> LO -> View.

> So while I cannot help to figure out what was causing it, I am 99% sure this
> was related to scaling somehow.
> 
> Feel free to close this bug.