Bug 1377293 - [Wayland] When typing fast at high CPU load, LibreOffice breaks key (letter) order
Summary: [Wayland] When typing fast at high CPU load, LibreOffice breaks key (letter) ...
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: libreoffice
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: WaylandRelated
TreeView+ depends on / blocked
 
Reported: 2016-09-19 11:42 UTC by Christian Stadelmann
Modified: 2019-05-22 20:51 UTC (History)
6 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 778019 None None None 2019-05-22 20:51 UTC

Description Christian Stadelmann 2016-09-19 11:42:45 UTC
Description of problem:
I was editing a PDF document with LibreOffice (Draw). When typing text into a text field, LibreOffice switched letters rendering the text I type broken.

Version-Release number of selected component (if applicable):
libreoffice-5.1.5.2-6.fc24.x86_64
libreoffice-5.2.1.2-2.fc25.x86_64

How reproducible:
* On two different machines, one with Fedora 24, one with Fedora 25.
* Only on wayland backend with libreoffice-gtk3, but not with GDK_BACKEND=x11 or SAL_USE_VCLPLUGIN=gen
* On different PDF documents
* Only on high CPU load. To simulate high CPU load, use cpulimit to reduce CPU time until typing has a noticeable lag in LibreOffice.
* Only on LibreOffice, not on other Gtk+ 3.x applications like gedit

Steps to Reproduce:
0. run `cpulimit --limit=10 libreoffice` if you are using a fast computer
1. Open a PDF document
2. edit any text field, e.g. typing "This is sparta"

Actual results:
"This is sparta" becomes "Thsi iss patra" or some other nonsense. Letters are correct, but in *randomized* order.

Expected results:
LibreOffice should not change letter order.

Comment 1 Christian Stadelmann 2016-09-19 11:50:21 UTC
(In reply to Christian Stadelmann from comment #0)
> * Only on high CPU load. To simulate high CPU load, use cpulimit to reduce
> CPU time until typing has a noticeable lag in LibreOffice.

The "high CPU load" case is often true just by running LibreOffice due to bug #1377298.


> * On different PDF documents

> 1. Open a PDF document

This issue is not only present for editing PDF documents, but for all documents. It is just easier to reproduce when editing PDF documents due to higher CPU load by LibreOffice. I can also reproduce in LibreOffice Writer. If you can't, try reducing the cpulimit.

Comment 2 Caolan McNamara 2016-09-19 15:45:59 UTC
We don't have any specific wayland code, so its the same gtk3 using-code under wayland or X. But it doesn't affect anyone else. There must be some bustage on our side I guess which is just more obvious under wayland

Comment 3 Christian Stadelmann 2016-09-19 16:37:06 UTC
(In reply to Caolan McNamara from comment #2)
> We don't have any specific wayland code, so its the same gtk3 using-code
> under wayland or X. But it doesn't affect anyone else. There must be some
> bustage on our side I guess which is just more obvious under wayland

That's interesting. No matter how hard I try I cannot reproduce this with LibreOffice on X11 or with any other Gtk+ 3.x application on wayland (evolution, gedit, gnome-contacts)

Comment 4 Christian Stadelmann 2017-09-19 10:32:12 UTC
The upstream issue has been closed as fixed, but I can still reproduce this issue by following these steps:

0. In a GNOME/Wayland session,
1. start libreoffice and open any document (I tested with writer)
2. use cpulimit to limit LibreOffice's CPU load, e.g. by running `cpulimit --limit=2 --pid=`pidof soffice.bin`
3. in the document, try typing very fast, i.e. faster than libreoffice can display the letters.
4. If you cannot type fast enough to make this bug appear, reduce the CPU limit or write a script which types into libreoffice.

What happens:
Letter order gets randomized. "This is sparta" becomes "Thsi iss patra" or some other nonsense. Letters are correct, but in *randomized* order.

What should happen:
Letters should show up in the same order I typed them.

Additional info:
I still cannot reproduce this bug in any other Gtk3-based application, even though I can limit their CPU to be slower than e.g. gnome-builder takes to display those letters I typed.

Installed software versions:
libreoffice-5.3.6.1-5.fc26.x86_64
gtk3-3.22.19-1.fc26.x86_64
mutter-3.24.4-1.fc26.x86_64
gnome-shell-3.24.3-1.fc26.x86_64
xorg-x11-server-Xwayland-1.19.3-4.fc26.x86_64

Comment 5 Christian Stadelmann 2017-09-19 10:37:05 UTC
(In reply to Christian Stadelmann from comment #4)
> […]

In that context: I don't get any warning messages like

> Key repeat discarded, Wayland compositor doesn't seem to be processing events fast enough!

when running into this bug in LibreOffice. If this were upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=777693, I should see these warning (which I do when keys repeat in incorrectly in e.g. Firefox).

Comment 6 Caolan McNamara 2017-09-19 14:47:24 UTC
without cpulimit, timestamp of events in our key up/down signal handler

time 1084252796 press 't'
time 1084252893 release 't'
time 1084252924 press 'h'
time 1084252988 release 'h'
time 1084253059 press 'i'
time 1084253136 press 's'
time 1084253141 release 'i'
time 1084253220 release 's'
time 1084253227 press ' '
time 1084253297 release ' '
time 1084253372 press 'i'
time 1084253434 release 'i'
time 1084253445 press 's'
time 1084253515 release 's'
time 1084253549 press ' '
time 1084253619 release ' '
time 1084253641 press 's'
time 1084253709 release 's'
time 1084253749 press 'p'
time 1084253799 press 'a'
time 1084253813 release 'p'
time 1084253917 press 'r'
time 1084253950 release 'a'
time 1084254014 release 'r'
time 1084254112 press 't'
time 1084254167 release 't'
time 1084254244 press 'a'
time 1084254313 release 'a'

Comment 7 Caolan McNamara 2017-09-19 14:48:07 UTC
under limit

time 1084313619 press 't'
time 1084313715 release 't'
time 1084313727 press 'h'
time 1084313952 release 'i'
time 1084313985 press 's'
time 1084314070 release 's'
time 1084314140 release ' '
time 1084314218 press 'i'
time 1084314384 release 's'
time 1084314406 press ' '
time 1084314480 release ' '
time 1084314545 press 's'
time 1084314972 release 'p'
time 1084315035 press 'a'
time 1084315291 release 'r'
time 1084313874 press 'i'
time 1084314305 press 's'
time 1084314622 release 's'
time 1084315196 press 'r'
time 1084313799 release 'h'
time 1084314907 press 'p'
time 1084315111 release 'a'
time 1084314068 press ' '
time 1084314290 release 'i'
time 1084315387 press 't'
time 1084315594 release 'a'
time 1084315533 press 'a'
time 1084315452 release 't'

Comment 8 Fedora End Of Life 2018-05-03 08:28:07 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 9 Milan Bouchet-Valat 2018-09-11 15:00:38 UTC
I still experience this on F28.


Note You need to log in before you can comment on or make changes to this bug.