(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.

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

(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)

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

(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).

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'

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'

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.

I still experience this on F28.

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-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 '30'.

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 30 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.

Still present with the same reproducer as in comment #4.

(In reply to Caolan McNamara from comment #7)
> under limit
> 
[...]
> time 1084313985 press 's'
[...]
> time 1084313874 press 'i'
[...]

I happen to be able to reproduce this rather reliably with a local LO master --with-lang=ALL ASan+UBSan build (i.e., which executes somewhat slowly):  When typing "file" in Writer right after it started up (but no longer after more typing), that gets garbled as "fiel".  (On Wayland; didn't check X11.)  Patching

> diff --git a/vcl/unx/gtk3/gtk3gtkframe.cxx b/vcl/unx/gtk3/gtk3gtkframe.cxx
> index 0960b46354d2..4d65f2a26db4 100644
> --- a/vcl/unx/gtk3/gtk3gtkframe.cxx
> +++ b/vcl/unx/gtk3/gtk3gtkframe.cxx
> @@ -3136,6 +3136,7 @@ gboolean GtkSalFrame::signalUnmap( GtkWidget*, GdkEvent*, gpointer frame )
>  
>  gboolean GtkSalFrame::signalKey(GtkWidget* pWidget, GdkEventKey* pEvent, gpointer frame)
>  {
> +    if(pEvent->type==GDK_KEY_PRESS)SAL_DEBUG("GtkSalFrame::signalKey "<<pEvent->time<<" "<<pWidget<<" "<<frame<<" <"<<pEvent->string<<">");
>      UpdateLastInputEventTime(pEvent->time);
>  
>      GtkSalFrame* pThis = static_cast<GtkSalFrame*>(frame);

into the LO master sources outputs

> debug:1729057:1729057: GtkSalFrame::signalKey 266652420 0x6290001d3220 0x6190006e9680 <f>
> debug:1729057:1729057: GtkSalFrame::signalKey 266652508 0x6290001d3220 0x6190006e9680 <i>
> debug:1729057:1729057: GtkSalFrame::signalKey 266652708 0x6290001d3220 0x6190006e9680 <e>
> debug:1729057:1729057: GtkSalFrame::signalKey 266652644 0x6290001d3220 0x6190006e9680 <l>

demonstrating that LO receives a sequence of GTK key-press-events with disordered time stamps.  (One sampled backtrace of reaching that GtkSalFrame::signalKey is

> #19 in GtkSalFrame::signalKey(_GtkWidget*, _GdkEventKey*, void*) at vcl/unx/gtk3/gtk3gtkframe.cxx:3166
> #24 in <emit signal ??? on instance 0x6290001d3220 [GtkWindow]> at /usr/src/debug/glib2-2.64.2-2.fc32.x86_64/gobject/gsignal.c:3554
>     #20 in _gtk_marshal_BOOLEAN__BOXED at /usr/src/debug/gtk3-3.24.20-1.fc32.x86_64/gtk/gtkmarshalers.c:83
>     #21 in g_closure_invoke at /usr/src/debug/glib2-2.64.2-2.fc32.x86_64/gobject/gclosure.c:810
>     #22 in signal_emit_unlocked_R at /usr/src/debug/glib2-2.64.2-2.fc32.x86_64/gobject/gsignal.c:3742
>     #23 in g_signal_emit_valist at /usr/src/debug/glib2-2.64.2-2.fc32.x86_64/gobject/gsignal.c:3508
> #25 in gtk_widget_event_internal at /usr/src/debug/gtk3-3.24.20-1.fc32.x86_64/gtk/gtkwidget.c:7808
> #26 in propagate_event at /usr/src/debug/gtk3-3.24.20-1.fc32.x86_64/gtk/gtkmain.c:2680
> #27 in gtk_propagate_event at /usr/src/debug/gtk3-3.24.20-1.fc32.x86_64/gtk/gtkmain.c:2724
> #28 in gtk_main_do_event at /usr/src/debug/gtk3-3.24.20-1.fc32.x86_64/gtk/gtkmain.c:1920
> #29 gtk_main_do_event at /usr/src/debug/gtk3-3.24.20-1.fc32.x86_64/gtk/gtkmain.c:1690
> #30 in _gdk_event_emit at /usr/src/debug/gtk3-3.24.20-1.fc32.x86_64/gdk/gdkevents.c:73
> #31 in gdk_event_source_dispatch at /usr/src/debug/gtk3-3.24.20-1.fc32.x86_64/gdk/wayland/gdkeventsource.c:124
> #32 in g_main_dispatch at /usr/src/debug/glib2-2.64.2-2.fc32.x86_64/glib/gmain.c:3309
> #33 g_main_context_dispatch at /usr/src/debug/glib2-2.64.2-2.fc32.x86_64/glib/gmain.c:3974
> #34 in g_main_context_iterate at /usr/src/debug/glib2-2.64.2-2.fc32.x86_64/glib/gmain.c:4047
> #35 in g_main_context_iteration at /usr/src/debug/glib2-2.64.2-2.fc32.x86_64/glib/gmain.c:4108
> #36 in GtkSalData::Yield(bool, bool) at vcl/unx/gtk3/gtk3gtkdata.cxx:382
> #37 in GtkInstance::DoYield(bool, bool) at vcl/unx/gtk3/gtk3gtkinst.cxx:384
> #38 in ImplYield(bool, bool) at vcl/source/app/svapp.cxx:455
> #39 in Application::Yield() at vcl/source/app/svapp.cxx:519
> #40 in Application::Execute() at vcl/source/app/svapp.cxx:434
> #41 in desktop::Desktop::Main() at desktop/source/app/app.cxx:1600
> #42 in ImplSVMain() at vcl/source/app/svmain.cxx:200
> #43 in SVMain() at vcl/source/app/svmain.cxx:232
> #44 in soffice_main() at desktop/source/app/sofficemain.cxx:98
> #45 in sal_main at desktop/source/app/main.c:48
> #46 in main at desktop/source/app/main.c:47

)

but why we suffer from this and other gtk-using apps don't appear to have the problem reported against them is a mystery to me

Maybe https://bugzilla.redhat.com/show_bug.cgi?id=1830580 is other gtk apps with the same problem?
And, even though that bug explicitly says it didn't happen in F31, I remember some time ago, maybe by F29 or F30, that gnome-shell's-everything-in-one-thread had some hiccups and I got scrambled letters everywhere, even with slow typing in gnome-terminal.

Its very possible, I've always been dubious that its entirely a fault on our side.

I've tried enforcing the CPUlimit onto several other applications (GEdit, KWrite, Epiphany, Firefox) so that they take several seconds to react to input. Still they do not mix up key/letter order at all.

(In reply to Stephan Bergmann from comment #12)
> I happen to be able to reproduce this rather reliably with a local LO master
> --with-lang=ALL ASan+UBSan build (i.e., which executes somewhat slowly): 
> When typing "file" in Writer right after it started up (but no longer after
> more typing), that gets garbled as "fiel".  (On Wayland; didn't check X11.) 

That's upstream <https://gerrit.libreoffice.org/c/core/+/94202> "Keep order of GDK input events intact", but which is apparently not a fix for the original issue from comment 0, as that states "Draw" while my fix is only for Writer.

ah, excellent. Very plausible to be a root cause for draw too though, no ?

(In reply to Caolan McNamara from comment #18)
> ah, excellent. Very plausible to be a root cause for draw too though, no ?

Facepalm.  How did I get the subliminal idea that my fix was Writer-specific.

lets try a backport of that for this

FEDORA-2020-57471f10a9 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-57471f10a9

FEDORA-2020-6a0a1abf6a has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6a0a1abf6a

FEDORA-2020-57471f10a9 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-57471f10a9`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-57471f10a9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-6a0a1abf6a has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6a0a1abf6a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6a0a1abf6a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

It looks quite like you have fixed this issue. Thank you very much! (will leave karma in bodhi).

FEDORA-2020-57471f10a9 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-6a0a1abf6a has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.