Bug 103708 - in Impress slides pane selecting a slide doesn't show it on every second click, instead runs different actions on it, occasionally even deleting it
Summary: in Impress slides pane selecting a slide doesn't show it on every second clic...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.1.6.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Slide-Page-Pane
  Show dependency treegraph
 
Reported: 2016-11-04 16:49 UTC by Simon Sievers
Modified: 2021-03-31 03:40 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Sievers 2016-11-04 16:49:01 UTC
Description:
In Libreoffice Impress in the slides pane I create 3 slides. Clicking on non-selected slides is supposed to select the slide and display it in the main window. Instead, on every second click, the slide clicked isn't selected and displayed, but a small paper icon on the top left of the window is displayed which floats to the clicked slide. Occasionally a slide is even deleted just by clicking / selecting it.

Happens every SECOND time clicking a slide, so it's quite reproducable. Though every other second click the slide clicked is selected as expected.

Steps to Reproduce:
1.Run Impress
2.Create three slides, title them slide 1 to 3
3.in the slide pane on the left by default click a slide not selected over and over again

Actual Results:  
alternating behaviour, fist click slide is selected, next click it isn't, every second click the clicked slide isn't selected as expected, occasionally and quite frequently, thus reproducable, a slide is even lost, then in the Edit->Undo menu the action to undo is "Delete Slides"

So on every other click, a different action is taken then selecting and displaying the slide clicked.

Expected Results:
Select the clicked slide and display its content in the main window in the middle.


Reproducible: Always

User Profile Reset: Yes! I even tried maximizing memory resources and fiddled with some options in the config. No effect on the misbehaviour.

Additional Info:
I have seen this bug a long time now and I cannot find any reports on it. I tested on a windows machine with libreoffice 5.2.1 and it hasn't been there, but on linux it is. I am not sure wether this bug is actually caused by libreoffice or something else. Most likely it's libreoffice but I have no clue why it would only occur on my linux system.

I am running Archlinux latest update with X and the Awesome window manager. Using other window managers / desktop doesn't solve the problem.

I would really like to start using Impress but this bug no matter what causes it keeps me back from it for almost a year now. Thanks for any efforts to solve this issue for me !!


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Comment 1 Simon Sievers 2016-11-07 13:16:26 UTC
The issue occurs when clicking different slides quite fast. How fast depends on the window manager used as it seems. Using awesome window manager and spectrwm reproduces the bug best as far as I know. In i3 the bug appears almost never. So far I have only been reproducing it on Archlinux. I am not sure about MS-Windows for now...

It's a major bug in my opinion. It renders LO impress useless! Silently losing slides is a catastrophy!
Comment 2 parchd 2016-11-07 13:48:38 UTC
Can reproduce on Arch using openbox as window manager, but not with the same frequency as the original bug report. I believe it is actually a drag event rather than a click event causing the problem. Reproducing requires very fast clicking between slides (or even on a single slide with a slight drag motion).
Comment 3 Buovjaga 2016-11-17 20:31:19 UTC
(In reply to parchd from comment #2)
> Can reproduce on Arch using openbox as window manager, but not with the same
> frequency as the original bug report. I believe it is actually a drag event
> rather than a click event causing the problem. Reproducing requires very
> fast clicking between slides (or even on a single slide with a slight drag
> motion).

I have discussed this same problem before: bug 91908

The last comment has:
"After some tests I have to conclude that this is due to input devices (touchpad and mouse with kind of contact bounce)."

Simon, parchd: could this be related to your input devices?
Comment 4 Simon Sievers 2016-11-21 16:52:24 UTC
I used xf86-input-synaptics. Tried switching to xf86-input-libinput with "pacman -S xf86-input-libinput" which automatically deinstalls xf86-input-synaptics and then restarted X. Problem persists.

Here is some xinput output:

xinput --list

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Logitech USB Receiver                   	id=9	[slave  pointer  (2)]
⎜   ↳ Logitech USB Receiver                   	id=10	[slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=12	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=11	[slave  keyboard (3)]
    ↳ Logitech USB Receiver                   	id=13	[slave  keyboard (3)]

I notice there are two Logitech USB Receiver. Disabling id=9 makes the mouse not work anymore, disabling id=10 has no effect. I notice the same problem with libreoffice impress using my touchpad, no matter wether using synaptics or libinput driver.

I notice "xinput --disable 12" makes the problem disappear. id=12 is my touchpad as you can see from the xinput output.

Then, turning back on the touchpad with "xinput --enable 12" both the mouse and the touchpad don't show the problem.

Maybe something goes wrong at boottime initializing the touchpad.

Haven't tested the disable / enable workaround with synaptics input driver.
Comment 5 Simon Sievers 2016-11-21 16:56:29 UTC
Terminating libreoffice and restarting it again the problem was there again. The disable / enable didn't solve it then. Seems to have been coincidence it ever did.
Comment 6 Simon Sievers 2016-11-21 17:50:35 UTC
Tried one more USB mouse with a cable, same problem persists. So a hardware failure would be really unlikely. Wanted to add this, just to be sure.
Comment 7 Simon Sievers 2016-11-21 21:27:22 UTC
I used xinput --test to view the events the mouse clicks cause in libreoffice window. It shows there is always just the correct event, like button press and button release one time each, even though delete gets caused.

In addition to the previous test all this leads me to the conclusion that the input device and input device drivers wouldn't be the culprit.

Any further help and suggestions greatly appreciated. Still I am not at all sure what the cause for the misbehaviour is and it might very well not be libreoffice.
Comment 8 Buovjaga 2016-11-24 07:43:37 UTC
Let's set to NEW as we have two people experiencing this and it doesn't seem to be related to input devices.
Comment 9 Simon Sievers 2017-02-02 18:44:40 UTC
Tested with different libreoffice backends by uncommenting lines in /etc/profile.d/libreoffice-still.sh, but problem persists. Tested kde4 and gtk with libreoffice-still.
Comment 10 Simon Sievers 2017-11-23 12:22:35 UTC
Tested again today with latest archlinux and libreoffice-fresh 5.4.3-3 and the problem still persists.
Comment 11 QA Administrators 2018-11-24 03:44:00 UTC Comment hidden (obsolete)
Comment 12 mattia.b89 2019-02-02 22:08:39 UTC
Cannot reproduce the issue, in:

Version: 6.1.4.2
Build ID: 6.1.4-4
CPU threads: 4; OS: Linux 4.20; UI render: default; VCL: gtk3; 
Locale: it-IT (en_GB.UTF-8); Calc: group threaded
Comment 13 QA Administrators 2021-03-31 03:40:54 UTC
Dear Simon Sievers,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug