This delay also affects the context menu (right mouse click) on gtk3 applications under wayland. It does not affect the context menu on gtk2 applications.

This lag can be seen in some more different situations:

When gtk3 windows are built. Steps to reproduce:
1. Open nautilus
2. right-click on some folder (you will see the lag while the menu is being displayed as described in Comment #1)
3. select "open in new window"
You will see a mouse lag until the new window is finished to display.

When you move the mouse cursor over window decorations from one window to the next.
1. Open 2 applications (this bug is present with any combination of gtk2, gtk3 and qt applications)
2. move the mouse cursor from one application to the next
You will see a slight mouse lag

When gnome-shell notifications are displayed
Every time gnome-shell displays a notification this causes a mouse lag too.

When a gtk3 window gets focused.
1. open 2 gtk3 windows (e.g. nautilus) beside each other
2. select (focus) one of them
3. select (focus) the other one
You will notice a mouse lag. This depends on the application type. It seems like this depends on the number of visible UI items: focusing a nautilus window with many items in the currently opened folder and a sidebar takes much more time than focusing an empty gedit window. This only affects gtk3 windows.

In gnome-shell activities overview when switching to the application list
1. in gnome-shell go to activities overview
2. press the symbol with 9 squares to open the application list
You will notice a mouse lag.

As a side note: I am running gnome-shell with animations disabled so I expect all of these operations to be calculated in no time. I am running Fedora 22 on recent hardware with 2 or more CPU cores > 3GHz, nothing older than 5 years, fast RAM, and a GPU which is able to do this under X without problems.

There is a related upstream GNOME Bug #745032 - Mouse Tracking 'Laggy' on Wayland

According to upstream bug report this is a issue with mutter (not gtk+).
Citing Jasper St. Pierre:
> The current theory is that stuff like creating actors, uploading textures to the GPU, etc. all block the main loop.

I can easily reproduce this with gnome-terminal. If you open a gnome-terminal with XDG_BACKEND=wayland, the lag is several times worse.

I have the same issue. Weston runs fast, Gnome-shell runs slow. It's not only menus but anything changing the mouse cursor, like hovering over window edges or hovering things in Google Chrome (extremely slow). Moving the mouse in a circle over Chrome makes the circle degrade to a spiral. Maybe it's time to rewrite the shell in a proper language?

https://bugzilla.gnome.org/show_bug.cgi?id=749783

This issue is still present on F23, but it is less noticeable.

This issue is not limited to menus (as pointed out in comment #5). It seems to affect all kinds of user interfaces. Another way to reproduce:

1. install libreoffice-gtk3
2. start libreoffice-gtk3 with GDK_BACKEND=wayland (this is the default as of writing these lines)
3. open any component of libreoffice, e.g. writer

You will see a long lag, the whole UI freezes for several seconds!

On F24 this issue is still present, but barely noticeable. The lag rarely is more than one second, mostly during gnome-shell fading notifications in.

Yeah well, it's important to keep in mind that *any* regression compared to X is completely unacceptable and makes the whole idea of "upgrading" the graphics stack to Wayland a failure. My bug got marked as a duplicate of this, even though it has nothing to do with gtk3. I get terrible performance in gnome shell on Wayland. I cannot think of anything more frustrating and anti-immersive than having the mouse cursor lag and drop movements compared to your physical hand movements. I would say this is an absolute critical bug until it is better than X.

A similar upstream bug causing lags and freezes, but I'm not sure they are just over Gtk+ 3.x applications: https://bugzilla.gnome.org/show_bug.cgi?id=760745

I suspect what you are experiencing here is because the Wayland compositor (mutter/gnome-shell) is in charge of managing everything, including the input devices and moving the pointer, so that when mutter/gnome-shell is busy dealing with /something/ else, the mouse pointer will lag.

I encounter the same mouse lag problem when I move my mouse over the categories of the Applications menu, that I installed using this extension https://extensions.gnome.org/extension/6/applications-menu/

I have found that certain extensions cause this issue.  If I disable shell extensions using the tweak tool, the lag disappears.  There are at least two extensions that appear to be problematic: [Task Bar](https://github.com/zpydr/gnome-shell-extension-taskbar/issues/166) and  
[All Windows](https://extensions.gnome.org/extension/704/all-windows/).  Disabling these just two extensions fixed the problem for me. 

It seems the issue might be something to do with extensions that poll open windows.  If I disable the "tasks" feature in TaskBar, the problem goes away.  Also, the problem grows worse as if I have lots of open windows open.

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. 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 '25'.

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 25 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 also observe this with Fedora 26

See also https://bugzilla.redhat.com/show_bug.cgi?id=1518722

Fedora 26, GNOME Shell 3.24.3

I am suffering a mouse lag problem too, especially when I right click within some application (evolution): menus open with a very noticeable delay. 

It started to happen after I  installed chrome-gnome-shell, but it still there after I removed it. Unfortunately I do not have a log of what else dnf installed with chrome-gnome-shell.

From tweaks/tools I have all extensions on Off, but mouse still lags.

Also:

delay is around 4 seconds within gedit. I noticed that even top bar clock is stuck: meanwhile I wait that the menu pops up, clock does not run.

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.

Still happens sporadically in F27, F28.

*** Bug 1597151 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. 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 '28'.

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

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

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

Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.