Bug 131467 - Positioning of mouse on "Default Button" not working with some dialogs
Summary: Positioning of mouse on "Default Button" not working with some dialogs
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.4.0.0.alpha0+
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:7.4.0 target:7.3.0.2
Keywords: bibisected, bisected, regression
Depends on:
Blocks: KDE, KF5
  Show dependency treegraph
 
Reported: 2020-03-21 16:36 UTC by Pinco Pallino
Modified: 2022-02-16 16:18 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pinco Pallino 2020-03-21 16:36:10 UTC
Description:
Positioning of mouse on "Default Button" not working with some dialogs.

Steps to Reproduce:
1.Set "Options"-"View"-"Mouse"-Positioning" to "Default button".
2.Copy some cells in Spreadsheet.
3.Move to other cell in sheet and from contextual menu choose "Paste Special"-"Paste Special..."


Actual Results:
"Paste Special" dialog open but mouse pointer is not on default button but suddenly moved far away to the left of the screen.

Expected Results:
When "Paste Special" dialog opens mouse pointer should be on the "OK" button which should be selected.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Using LibreOffice downloaded from document foundation site. It is working properly in version 6.2.
Tested with a clean new user profile. It happens both with OpenGL enabled and disabled.
With some dialogs, like "File Save" the positioning is working as expected. Problem is not random: with a given dialog it either always work or always does not work, it depends on the dialog.
Comment 1 m_a_riosv 2020-03-21 20:01:39 UTC
I can't repro on windows.
Version: 7.0.0.0.alpha0+ (x64)
Build ID: 61d8d991a27c3bfe70e3b8d3b4ce4d8a41d18d2d
CPU threads: 4; OS: Windows 10.0 Build 19587; UI render: Skia/Vulkan; VCL: win; 
Locale: es-ES (es_ES); UI-Language: en-US Calc: threaded
Comment 2 Pinco Pallino 2020-03-23 09:52:46 UTC
I have run Libreoffice scalc 6.4.2.2  in a simple openbox environment to exclude possible effects of Plasma5.
The positioning of mouse pointer does not work for any dialog at all, totally broken. 
Tried Libreoffice 6.2.8.2 and it works always.
Comment 3 Buovjaga 2020-05-17 18:21:32 UTC
Please copy and paste here the contents of your Help - About. This allows us to know more about your system.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.
Comment 4 Pinco Pallino 2020-05-17 18:38:56 UTC
Dear Buovjaga,

I have upgraded to 6.4.4.2 downloaded from document foundation site. The problem is still there in this latest version exactly as in 6.4.2.2 .
The contents of my Help - About are:

Version: 6.4.4.2
Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff
CPU threads: 8; OS: Linux 4.15; UI render: GL; VCL: kf5; 
Locale: es-ES (es_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 5 Buovjaga 2020-05-17 18:40:10 UTC
(In reply to Pinco Pallino from comment #4)
> Dear Buovjaga,
> 
> I have upgraded to 6.4.4.2 downloaded from document foundation site. The
> problem is still there in this latest version exactly as in 6.4.2.2 .
> The contents of my Help - About are:
> 
> Version: 6.4.4.2
> Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff
> CPU threads: 8; OS: Linux 4.15; UI render: GL; VCL: kf5; 
> Locale: es-ES (es_ES.UTF-8); UI-Language: en-US
> Calc: threaded

UI render: GL there jumps out at me. OpenGL UI rendering on Linux is known to be broken. Try deactivating it from Tools - Options - LibreOffice - View - Use OpenGL for all rendering
Comment 6 Pinco Pallino 2020-05-17 18:53:29 UTC
I have deactivated OpenGL as requested and rebooted computer just in case.

Unfortunately the problem is still there, no difference at all.

Version: 6.4.4.2
Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kf5; 
Locale: es-ES (es_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 7 Buovjaga 2020-05-17 18:55:51 UTC
Try launching from the command line with

SAL_USE_VCLPLUGIN=gen libreoffice
Comment 8 Pinco Pallino 2020-05-17 19:30:04 UTC
Dear Buovjaga,

when launching with SAL_USE_VCLPLUGIN=gen libreoffice  the problem with the dialogs is gone. I have tested all the possibilities and the problem is not there anymore  :-)
I must say, however, that the interface does not look as nice as before.

Version: 6.4.4.2
Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: x11; 
Locale: es-ES (es_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 9 Buovjaga 2020-05-18 06:46:32 UTC
The gen/x11 backend is only a fallback. Perhaps it could be removed some day when the others are polished enough.

You could also test with

SAL_USE_VCLPLUGIN=gtk3 libreoffice

to see, if the problem is only with the KDE Frameworks backend (kf5)
Comment 10 Pinco Pallino 2020-05-18 08:48:59 UTC
Dear Buovjaga,

As you suggested I have tried with 

SAL_USE_VCLPLUGIN=gtk3 libreoffice

The problem is back. With some dialogs (the same as kf5 back-end) the mouse pointer does not position itself on the default option, although that option is active.
With gtk3 the situation is a bit better that with kf5 in the sense that with the former the pointer does not move, while with kf5 it jumps suddenly somewhere to the left.

Only with gen/x11 back-end it works exactly as expected.
I don't mind using the gen/x11 if there was a way to increase the font size of the UI, because the text of the menu is very very small.

Until version 6.2 the kf5 and gtk3 back-end works perfectly.
Comment 11 Buovjaga 2020-05-22 12:36:22 UTC
I reproduce the problem.

Arch Linux 64-bit
Version: 7.0.0.0.alpha1+
Build ID: 809ddff82dc9a28051d8f6b0d6513b1824ba0ab9
CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5; 
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 19 May 2020
Comment 12 Buovjaga 2020-05-22 12:51:18 UTC
Bibisected with Linux 6.4 repo to https://git.libreoffice.org/core/+/bbbc820d7920a31669cb7e9aaeb5beb072eae175%5E!/

Qt5 don't assert broken height or width

Adding Cc: to Jan-Marek Glogowski

The funny thing is: with gtk3, the mouse does not move anywhere (behaviour unchanged between commits).
Comment 13 Pinco Pallino 2020-10-22 12:45:16 UTC
The problem is still there in the latest versions, both using kf5 and gtk3

The problem persists in:

Version: 6.4.7.2
Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kf5; 
Locale: es-ES (es_ES.UTF-8); UI-Language: en-US
Calc: threaded

and in

Version: 7.0.2.2
Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kf5
Locale: es-ES (es_ES.UTF-8); UI: en-US
Calc: threaded

Regards,
Comment 14 Commit Notification 2021-12-21 12:36:21 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ca28826a087245686d7fca3ffc8ca1f03307924d

tdf#131467 Qt set default position on first resize

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.
Comment 15 Jan-Marek Glogowski 2021-12-21 12:43:56 UTC
Please open a new bug report for gtk3, if that problem still happens there. This was a VCL plugin specific bug. I didn't check gtk3.
Comment 16 Commit Notification 2021-12-22 04:01:32 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/4d30c63bd0652c75cda9c57ef21c4cfe65df184f

tdf#131467 Qt set default position on first resize

It will be available in 7.3.0.2.

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.