Closed Bug 1615098 Opened 6 years ago Closed 5 years ago

[Wayland] Mouse hovering broken on Firefox 73

Categories

(Core :: Widget: Gtk, defect, P3)

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla76
Tracking Flags:
Tracking Status
firefox74 --- wontfix
firefox75 --- fixed
firefox76 --- fixed

People

(Reporter: michelesr, Assigned: stransky)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Bug 1615098 [Wayland] Set opaque region to toplevel window only, r?jhorak
47 bytes, text/x-phabricator-request
jcristau
: approval-mozilla-beta+
Details | Review

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

Steps to reproduce:

Couldn't find a specific way to reproduce, it just happens after a while (usually less than 1 minute).

Actual results:

Hovering on items with the mouse seems to have no effect, the cursor won't change icon depending on the page element that is hovering (e.g. link, or text field), and elements won't highlight (for example when hovering over tabs). Also resizing the window seems to cause visual artifacts (glitches, like flickering black bands and so on), and once Firefox even managed to crash with this crash report: https://crash-stats.mozilla.org/report/index/8bb4c636-7c1c-451f-aa3e-fcee50200212

Expected results:

Nothing of the above mentioned should happen, like in Firefox 72.

OS: Arch Linux (Linux 5.5.2 x86_64)
Desktop Environment: GNOME 3.34.2, with Wayland 1.17.0

Also when selecting text, the selected text is not higlighted until you release the mouse click. It's like the application doesn't understand the cursor position until you actually click.

A potential way to reproduce (on GNOME):

  • open Firefox with GDK_BACKEND=wayland
  • maximize the window (not fullscreen)
  • move the mouse to the top of the screen, and try to drag horizontally left and right
  • now move the cursor back on Firefox, and you will see that icon doesn't update
  • move the cursor on a position on the screen, and click: now the cursor icon updates based
  • try to select text, text won't be highlighted until you release the mouse to end the selection

The bug seems to be triggered also by other random actions, which I couldn't figure out exactly.

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

Same thing happens on my machine.
OS: Arch Linux with Linux 5.5.3 x86_64
DE: GNOME 3.34.3 with Wayland 1.18.0
GPU: AMD Radeon RX 5700 XT (Navi 10)

To reproduce this, you can also try playing videos on YouTube after launching Firefox with Wayland backend and maximizing the window.
Switching video to fullscreen mode the first time freezes the video while the audio keeps playing.
Pressing F to disable fullscreen mode and alt-tabbing twice fixes the issue (including cursor hovering), but after a few minutes, both cursor hovering and fullscreen mode break again.

I don't see that on Fedora 31 with gnome-shell-3.34.3-1.fc31.x86_64.
Do you have anything interesting in dmesg or journal?
Also maybe you can run firefox as:

WAYLAND_DEBUG=1 firefox

and check which events are logged when the freeze happens. You can also log wayland widget drawing by:

MOZ_LOG="WidgetWayland:5" firefox

Blocks: wayland
Priority: -- → P3

Also can you try latest nightly if you see the problem?

Flags: needinfo?(michelesr)

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

I don't see that on Fedora 31 with gnome-shell-3.34.3-1.fc31.x86_64.
Do you have anything interesting in dmesg or journal?
Also maybe you can run firefox as:

WAYLAND_DEBUG=1 firefox

and check which events are logged when the freeze happens. You can also log wayland widget drawing by:

MOZ_LOG="WidgetWayland:5" firefox

No errors in dmesg or gnome-shell journal.
While I don't see anything weird with WAYLAND_DEBUG set, there's a bunch of messages like this with MOZ_LOG="WidgetWayland:5":

[Parent 52463: Compositor]: D/WidgetWayland moz_container_get_wl_surface [0x7f896bef9570] surface (nil) ready_to_draw 0
[Parent 52463: Compositor]: D/WidgetWayland moz_gtk_widget_get_wl_surface [0x7f896bef9570] wl_surface 0x7f897194fd80 ID 85
[Parent 52463: Compositor]: D/WidgetWayland moz_container_request_parent_frame_callback [0x7f896bef9570] frame_callback_handler 0x7f896c695380 frame_callback_handler_surface_id 85
[Parent 52463: Compositor]: D/WidgetWayland     [0x7f896bf0f000] mWindow->GetWaylandSurface() failed, delay commit.
[Parent 52463: Compositor]: D/WidgetWayland WindowSurfaceWayland::DelayedCommitHandler [0x7f896bf0f000]
[Parent 52463: Compositor]: D/WidgetWayland WindowSurfaceWayland::CommitWaylandBuffer [0x7f896bf0f000]
[Parent 52463: Compositor]: D/WidgetWayland    mDrawToWaylandBufferDirectly = 1
[Parent 52463: Compositor]: D/WidgetWayland    mCanSwitchWaylandBuffer = 0
[Parent 52463: Compositor]: D/WidgetWayland    mDelayedCommitHandle = (nil)
[Parent 52463: Compositor]: D/WidgetWayland    mFrameCallback = (nil)
[Parent 52463: Compositor]: D/WidgetWayland    mLastCommittedSurface = (nil)
[Parent 52463: Compositor]: D/WidgetWayland    mBufferPendingCommit = 1
[Parent 52463: Compositor]: D/WidgetWayland    mBufferCommitAllowed = 1

I can't seem to catch this behavior on Nightly

I can reproduce on my system.

Linux: 5.5.4
Gnome: 3.34.2
Mesa: 19.3.4
GPU Driver: amdgpu

I can only reproduce the issue under the following setup:

  • MOZ_ENABLE_WAYLAND=1
  • MOZ_WEBRENDER=1
  • Firefox is launched into an already maximized window state

Let me know if there are any debug flags I can turn on to get more detailed info that might be useful for debugging.

firefox 73.0.1-1
gnome-shell 1:3.34.4-1
mutter 3.34.4-1
wayland 1.18.0-1
wayland-protocols 1.18-1
mesa 19.3.4-2
linux 5.5.4.arch1-1 (i915)

If Firefox is maximized (Independently of 'scaled-monitor-framebuffer') it doesn't change the state of cursor or page (:hover, selection, etc) basing on just the cursor movement. But any key/button press triggers the update, including selection progress.

Once I was able to 'fix' this behaviour with several sends of an expanded Firefox window from one monitor to another with Alt+Tabbing to another window on the same workspace.

The same issue happens on my system on Arch Linux with firefox using wayland in a gnome session.
The software versions are identical to what ettavolt mentioned in the previous comment.

When that bug occurs I am unable to move tabs between firefox windows, to create a new window by dragging the tab down, not even move a tab position in the top list, and putting a video into full screen glitches everything to the point I have to kill firefox.

This behaviour started after updating from firefox 72.

Same happens to me too using ArchLinux, Wayland, scaled-monitor-framebuffer and MOZ_ENABLE_WAYLAND=1, with the same versions @ettavolt is mentioning. This seemed to have started in Firefox 72 or 73 but I also remember upgrading wayland so unsure what's exactly what started the problem.

I don't think is Wayland. I'm now using Firefox 72 on Arch Linux with GDK_BACKEND=wayland and can't reproduce.

I found a way to 'fix' it for several restarts:

  1. Launch maximized on one display.
  2. Send to another.
  3. Send back to first. Here you should observe that window didn't move or is pixelized.
  4. Switch workspaces back and forth, maybe twice.

For reference: I have active framebuffer scaling and WebRender disabled, first display is unscaled, the second is 1.25x. (Gnome Shell, etc, like already written)

Am also affected with the same set-up as leebickmtu. I cannot pin down what triggers it but it starts after a few minutes of usage.

This should be covered in bug 1609538. Oddly, this should only happen in GS 3.35/3.36, not on 3.34. Do all affected parties here use Arch, and does Arch by chance ship https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/918 on top of 3.34?

Yes, it's there since December:
https://git.archlinux.org/svntogit/packages.git/log/trunk/0002-surface-actor-wayland-Do-not-send-frame-callbacks-if.patch?h=packages/mutter
Preliminary optimization, isn't it? :)
Guess, we'll need to ask Arch maintainers to include that FF patch from bug 1609538.

(In reply to ettavolt from comment #17)

Yes, it's there since December:
https://git.archlinux.org/svntogit/packages.git/log/trunk/0002-surface-actor-wayland-Do-not-send-frame-callbacks-if.patch?h=packages/mutter
Preliminary optimization, isn't it? :)
Guess, we'll need to ask Arch maintainers to include that FF patch from bug 1609538.

Good to know, thx!

For the record, this bug should become even more visible with webrender/ogl after bug 1618493 landed - after all this bug should always appear when firefox is maximized or fullscreened.

This should be fixed in bug 1609538 (making this a duplicate of it). So best would be if Arch backports that one to their firefox build.

Meh, it's not completely fixed in bug 1609538 yet.
For a proper solution see also the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1609538#c29 and https://bugzilla.mozilla.org/show_bug.cgi?id=1609538#c31

(In reply to robert.mader from comment #21)

Meh, it's not completely fixed in bug 1609538 yet.
For a proper solution see also the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1609538#c29 and https://bugzilla.mozilla.org/show_bug.cgi?id=1609538#c31

Sorry, false alarm. With the new Fedora 32 build, which includes the hotfix from bug 1609538, this error here appears to be mostly gone (only some small corner cases remain that we can better fix with a proper solution later). So arch users, please go for that one :)

(In reply to robert.mader from comment #22)

(In reply to robert.mader from comment #21)

Meh, it's not completely fixed in bug 1609538 yet.
For a proper solution see also the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1609538#c29 and https://bugzilla.mozilla.org/show_bug.cgi?id=1609538#c31

Sorry, false alarm. With the new Fedora 32 build, which includes the hotfix from bug 1609538, this error here appears to be mostly gone (only some small corner cases remain that we can better fix with a proper solution later). So arch users, please go for that one :)

Robert, I still see that with Firefox 74 + the patch included, it's especially visible for popup windows in RH bugzilla. I'll try Firefox 75 when comes out, it seems to work much better.

What are the differences between Arch Linux and Fedora exactly? Aren't they both using upstream GNOME and Wayland?

The fix in bug 1609538 made no difference for me, neither on mouse hover nor YouTube behavior.

Running Gnome/Wayland on Arch Linux.

Unsure if others are facing the same issues I'm facing but after upgrading to:

firefox 74.0-1
gnome-shell 1:3.36.0-1
mutter 3.36.0-1
wayland 1.18.0-1
wayland-protocols 1.20-1

Firefox is working very badly. It takes ages to switch to a different tab, takes ages to open a link, things turned out completely unusable :(.

The fix from 1609538 is merged to 75 only. I'll try to do an arch chroot build and then convince maintainers to include the patch for time being.

@spastorino, @ettavolt, the fix currently in Nightly is not enough yet so I wouldn't waste my time with it. A "good" workaround is to not maximise the FF window...

Can you try to set widget.wayland.use-opaque-region to false at about:config in latest nightly and try again? It should workaround the opaque region issues but may come with worst performance under Mutter.
Thanks.

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

Can you try to set widget.wayland.use-opaque-region to false at about:config in latest nightly and try again?

This works for me, thank you. Performance impact is much less noticeable than this bug.

Another related symptom that wasn't mentioned above: autoscroll also doesn't work.

One workaround that sometimes works for me is un-maximize and re-maximize the window.

I've finally (my pure laptop!) built 74.0b9 with the patch from bug 1609538. Quick tries didn't yield the reproduction of this bug. Was running it with just MOZ_ENABLE_WAYLAND=1.
However, I'm still on Gnome 3.34 (build with that optimization patch). I promise more results once I deal with Gnome Shell extension upgrades. :)

Flags: needinfo?(michelesr)

Quick update: the patch from bug 1609538 does not reliably fix this issue - I won't go into details here but I simply confused how we (or Wayland compositors in general if they optimize heavily) issue frame callbacks. So while the patch can make the issue here go away, it would reappear sooner or later.

So for the moment I think what we need to do is to not set an opaque region on the container surface at all until we find a way how to process input events differently. That being said, it would be really sad to loose opaque regions completely as overpaint etc. can escalate quite quickly - lets say we have three FF windows stacked on top of each other (each having two surfaces). That is six surfaces, potentially maximized, to be drawn. That can quickly exhaust memory bandwidth, especially on 4K.

So I'll put together a patch that only sets the opaque region for toplevel surfaces - if that works well, we will constantly have 100% overpaint, but at least not limitless (not even talking about frame callbacks to hidden windows, which this approach would also avoid). That should fix this issue for everyone at an acceptable cost.

Assignee: nobody → stransky

Robert, there's the patch attached, feel free to check it.

Flags: needinfo?(robert.mader)

LGTM and from my testing I can verify that it:

  • reliably fixes the issue here
  • correctly sets the opaque region on the window as a whole, so we at least do not paint client / background hidden behind Firefox
  • does not introduce new glitches like I saw when adding the if statement

So yep, lets go with that. Also, I'll apply for commit permissions NOW.

Flags: needinfo?(robert.mader)

Still stumbling in the dark to some extends, but it appears that there is indeed a GTK bug lurking below this - I managed to reproduce the same bug (most likely) in a pure GTK app (https://gitlab.gnome.org/GNOME/gtk/issues/2511). If we can fix that, it should allow us to reintroduce opaque regions on container surfaces again. Never the less we should push the patch from above for the time being.

Pushed by rgurzau@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f0c12aaf4399 [Wayland] Set opaque region to toplevel window only, r=jhorak

We may need to backport it to 75 too.

status-firefox74: --- → wontfix
status-firefox75: --- → affected
status-firefox76: --- → affected

Does this mean that the workaround from comment 29 is not needed anymore in the next nightly?

(In reply to spineeye from comment #39)

Does this mean that the workaround from comment 29 is not needed anymore in the next nightly?

Yes, you should not need that.

https://hg.mozilla.org/mozilla-central/rev/f0c12aaf4399

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
status-firefox76: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla76

Please backport that to FF75. I guess that this is the one that will ship on the upcoming Ubuntu LTS image.

Comment on attachment 9132890 [details]
Bug 1615098 [Wayland] Set opaque region to toplevel window only, r?jhorak

Beta/Release Uplift Approval Request

  • User impact if declined: Broken screen refresh on Wayland / Mutter 3.36.
    Due to wrong opaque region handling in mutter Firefox is not repainted and looks inactive to uses on Fedora 32.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Linux/Wayland only.
  • String changes made/needed: none
Attachment #9132890 - Flags: approval-mozilla-beta?

Comment on attachment 9132890 [details]
Bug 1615098 [Wayland] Set opaque region to toplevel window only, r?jhorak

ok, i guess... approved for 75.0b5

Attachment #9132890 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

I am facing this issue with Firefox 76 , while running the automation scripts mouse hovering is not working for the second time. Any solution to handle it?

I have been experiencing this same issue with Firefox Nightly for the past several months whenever I tried to use widget.wayland.use-opaque-region, though the steps to reproduce the issue are different.

In GNOME 3.36 or 3.38 on Ubuntu:

  1. Make Firefox fullscreen, either by pressing Fn+F11 or by making a video fullscreen
  2. Either use the four-finger swipe gesture to switch between workspaces (Super+PgUp/Dn will not suffice), or open Activities, the method of opening Activities does not matter

If you simply don't make Firefox fullscreen, regardless of window size, or you simply never open Activities or switch to another workspace using the touchpad gesture, then you will not encounter this issue.

To recover proper pointer interaction, the following steps are needed:

  1. Make Firefox no longer fullscreen
  2. Either switch to another workspace using the aforementioned gesture, or open Activites

Here's hoping that somebody notices in a timely manner. Oh, also, I would record a screencast, but GNOME Shell's internal screencast plugin was somehow broken by the upgrade from Ubuntu Focal to Ubuntu Groovy. If I manage to get it working again, I will record a screencast immediately.

I have just discovered that simply disabling the title bar results in the same outcome as having Firefox in fullscreen mode.

Enabling widget.wayland.use-opaque-region is tracked in bug 1668805 - until then it's expected to be broken on compositors that apply frame callback optimizations.

(In reply to Robert Mader [:rmader] from comment #50)

Enabling widget.wayland.use-opaque-region is tracked in bug 1668805 - until then it's expected to be broken on compositors that apply frame callback optimizations.

Oh, I thought that this was the bug for the configuration option as this is the only bug which came up when searching for the configuration option 😅.

Thank you for your response!

Don't know if this is still open, but I'm having the same issues as discussed above (pointer position not being updated until mouse click or scroll, selecting text with mouse doesn't highlight the selection until mouse release, same with scroll bar...)

Also don't know how to reproduce it, seems to happen on its own after some time, aprox. half an hour.
If I restart the browser everything goes back to normal.
Also curiously, if I open a new window, the issue will go away in the new window but remain in the old one.

Using Firefox v104.0 on Ubuntu 22.04

Hi

I have exactly the same problem as Danilo Markovic :
-mouse doesn't highlight the selection until mouse release
-same with scroll bar
-If I restart the browser everything goes back to normal
-if I open a new window, the issue will go away
-hard to reproduce, seems to happen on its own after some time

Google map is unusable.

Debian GNU/Linux bookworm/sid
linux-image-5.18.0-4-amd64/unstable,now 5.18.16-1 amd64 [installed,automatic]
libc6/unstable,now 2.34-7 amd64 [installed]
libwayland-*/unstable,now 1.21.0-1 amd64 [installed,automatic]
gnome-shell/unstable,now 42.4-1+b1 amd64 [installed]
firefox/unstable,now 104.0-1 amd64 [installed]

Please tell me how I can help / config so I can use firefox again ?
Thank you !

Hello,
I arrived here when searching for similar issues, and I can attest I have the exact same issue as Danilo Markovic and linux_ready_for.

I have exactly the same problem as Danilo Markovic :
-mouse doesn't highlight the selection until mouse release
-same with scroll bar
-If I restart the browser everything goes back to normal
-if I open a new window, the issue will go away
-hard to reproduce, seems to happen on its own after some time

Dragging in Google Map is impossible. Clicking works, but not dragging.

I can screen record, if it helps.

Also in Debian Sid, Gnome, Wayland and Firefox with the same versions as linux_ready_for.

Hello,

sorry for bumping, but I'll also share my specs:
boomwork/sid, wayland, gnome 42.4, amd x86_64, 2 monitors.

Just adding to it, I'm also using an external monitor.

And, as noted by Sandi Vujaković, if Firefox is no longer in full screen, things go back to normal. So, for now the workaround is to resize the window until it's "almost" full screen. Then, everything gets usable again.

(In reply to roni-96 from comment #55)

Hello,

sorry for bumping, but I'll also share my specs:
boomwork/sid, wayland, gnome 42.4, amd x86_64, 2 monitors.

Thanks. Which exact GTK-3 version do you have? 3.24.34-3 ?

(In reply to Virgilio Vasconcelos from comment #56)

I have no such workaround in my case : the problems described remain, firefox being fullscreen or not.

(In reply to Robert Mader [:rmader] from comment #57)

libgtk-3-*/unstable,now 3.24.34-3 amd64 [installed,automatic]

Note also that this bug have been there for quite some time in my case... I would say several months (and the corresponding firefox, wayland, gtk, versions in the rolling release debian).

I'm also facing this issue on Wayland when using multi monitor. I noticed it's easily reproducible when I'm using alt+tab to navigate between windows. It's happening randomly so to reproduce this problem just keep using Firefox for a few minutes and try pressing alt+tab (or even sometimes it's just alt).

I know this is an old bug, but with the recent additions, and the fact that it's been happening for me for months, I thought I'd post my findings.

I'm a web developer, so this bug happens frequently and makes work really difficult.
A quick fix when it happens is to close the window and open it back up again, or if I've got a separate Firefox window open, move the tab over there and then into it's own window.

Having testing it a few times, it only seems to happen when I've got the IDE open and/or running yarn serve/npm run serve.
I'm not sure if it's one or the other, or both, but basically the IDE and the "tab with issue" are both on the same screen (multi-screen setup). I Alt+Tab between them, and then the hover effects stop working.
Once broken, moving the window to the second screen does not fix it. It is only when I move the tab(s) to a "working" firefox window.

I'm not sure if the altabbing is too quick, or if it breaks during the watch/changes.

When I have the "tab with issue" on the second monitor, and the IDE one the first, I cannot replicate it.
If I quick alt+tab with another Firefox window (different site), I cannot replicate it.

All windows have been maximised.

Hi @mohammad.rafigh @Quin452,

This is an old bug but have been affecting several people recently and still is.

I use the same workaround as you are : move the tab in its own window.

Please put your informations on the recent https://bugzilla.mozilla.org/show_bug.cgi?id=1789602

And Mozilla Firefox dev, please tell us how we could help.

It's happening for me with Firefox 105 (beta) on Wayland. So this (or similar) regression is back.

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

Attachment

General

Creator:
Created:
Updated:
Size: