Open Bug 1616309 Opened 4 years ago Updated 9 months ago

Mouse over on Wayland broken in FF 73

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Version:
72 Branch
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: towo, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

I have been running Firefox with MOZ_ENABLE_WAYLAND=1 for a while now.
I put my mouse cursor over on a link with mouse over effects (easiest example: the link underscore in Mozilla Bugzilla).

Actual results:

No mouse over effect.
When clicking on the link and holding, the mouse over effect appears. Scrolling up and down using the mouse wheel (or mouse wheel emulation, e.g. mmb + touchpad) will trigger the mouse over if the cursor ends up over the link text.

Expected results:

Mouse over working without hoops.

Further hints:

  1. When switching to Xorg, this doesn't happen.
  2. WebRender on/off has no influence on behaviour.
  3. Downgrading to FF 72 fixes the issue.

Yes, this bug shows up as 72 branch because I purposefully downgraded and stuck there, since this bug makes for a jarring experience otherwise.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

I can confirm this on Firefox 73.0.1 / Arch Linux package firefox-73.0.1-1 with MOZ_ENABLE_WAYLAND=1.

I'll also add some perhaps related observations:

  • Sometimes while moving the mouse, a second ghost mouse pointer flickers in a fixed position elsewhere on the screen.
  • I can reliably but briefly restore mouseover events by alt-tabbing to Terminal which I run on a different Gnome workspace and alt-tabbing back to Firefox. But shortly afterwards (within seconds) mouseover stops working again.
  • It also affects the rendering of text selection - while selecting text with the mouse on a web page, the visual highlight only appears on mouse-up, instead of throughout the mouse movement

(In reply to Paul Annesley from comment #4)

  • Sometimes while moving the mouse, a second ghost mouse pointer flickers in a fixed position elsewhere on the screen.

This particular issue remains after downgrading to Firefox 72, so please disregard it from the context of this bug.

FYI this bug still presents in Firefox 74.0

Ran into this bug, some further comments:

  • Normally I'm using FF in a maximized window, and when this happens, I click and hold leftmouse on the titlebar to resize, and mousewheel at the same time. This restores normal functionality, but shortly (within a minute or so) enters the buggy state again. Performing this workaround again always restores normal behaviour.
  • Using x11 backend, this bug doesn't happen.
  • Entering full screen media playback in this buggy state causes the initial full screen frame to display, but then no screen updates occur. Pressing Esc (exiting fullscreen) also doesn't update the screen, although it does work - using the above mentioned workaround restores normal behaviour, and updates the screen again normally.

(Oops forgot version info)
Was using FF 73.0.1 with MOZ_ENABLE_WAYLAND=1 at the time on Arch, have since switched to using x11 (unset MOZ_ENABLE_WAYLAND) as it was becoming too much.

Can confirm this to be present for a while now.
Currently occuring on Firefox Nightly 75.0a1 (2020-03-08) (64-bit) on latest Arch Linux with wayland.

I can also confirm this

It also affects the rendering of text selection - while selecting text with the mouse on a web page, the visual highlight only appears on mouse-up, instead of throughout the mouse movement

and this

Entering full screen media playback in this buggy state causes the initial full screen frame to display, but then no screen updates occur. Pressing Esc (exiting fullscreen) also doesn't update the screen, although it does work - using the above mentioned workaround restores normal behaviour, and updates the screen again normally.

For the fullscreen video case (last quote), my workaround is switching to another workspace and back to the current one, sometimes more than once. But almost always fixable this way.

What is needed for further diagnosis?

Additional info for bug behavior:
When pressing any keyboard button the rendering of the correct mouse cursor (hand), the hyperlink destination in the lower left or right corner and a potential hover effect is triggered without doing anything with the mouse. When moving away from an element that has a hover effect, the key press also triggers the rendering of the mouse cursor back to its normal state.

Just testest with firefox developer edition (firefox-developer-edition 75.0b7-1) and it seems be fixed.

After couple of days of using it, I found that there are still few glitches. Some pages do not load immediately. We need to switch to other window before it fully loads.

(In reply to friedrichin from comment #12)

After couple of days of using it, I found that there are still few glitches. Some pages do not load immediately. We need to switch to other window before it fully loads.

Can you try to set widget.wayland.use-opaque-region to false and check if you still see that?
Thanks.

(In reply to Martin Stránský [:stransky] from comment #13)

(In reply to friedrichin from comment #12)

After couple of days of using it, I found that there are still few glitches. Some pages do not load immediately. We need to switch to other window before it fully loads.

Can you try to set widget.wayland.use-opaque-region to false and check if you still see that?
Thanks.

Still does not seem to work.

Most of the links work but the ones that have ajax functionality needs alt+tab to fully load.

(In reply to friedrichin from comment #14)

Can you try to set widget.wayland.use-opaque-region to false and check if you still see that?
Thanks.

Still does not seem to work.

Most of the links work but the ones that have ajax functionality needs alt+tab to fully load.

Can you please file a new bug with a reproduction steps and cc me there?
Thanks!

Flags: needinfo?(friedrichin)
Severity: normal → S3

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(friedrichin)
You need to log in before you can comment on or make changes to this bug.