Closed Bug 1593478 Opened 2 years ago Closed 1 year ago

[Wayland/KDE] Nightly 71.0a1-72.0a1 on Wayland stopped responding after resizing on Plasma on Wayland

Categories

(Core :: Widget: Gtk, defect)

72 Branch
defect
Not set
normal

Tracking

()

RESOLVED MOVED

People

(Reporter: matthew.fagnani, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

847.73 KB, text/plain
Details

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

Steps to reproduce:

  1. Boot Fedora 31 KDE Plasma spin installation with kwin-wayland and its dependencies installed, fully updated with updates-testing enabled
  2. Log in to Plasma on Wayland from sddm
  3. install or update to firefox nightly 72.0a1 (2019-11-02)
  4. start konsole
    5 . change directory to that where nightly was installed, then run
    MOZ_ENABLE_WAYLAND=1 ./firefox &
  5. set layers.acceleration.force-enabled to true in about:config as recommended at https://bugzilla.mozilla.org/show_bug.cgi?id=1584845#c8
  6. close firefox
  7. MOZ_ENABLE_WAYLAND=1 ./firefox &
  8. Resize firefox by clicking on its right border and dragging it left.

Actual results:

I tried to resize 71.0a1-72.0a2 on Wayland with layers.acceleration.force-enabled=true by dragging the right border to the left, but the window wasn't resized. After trying to resize the window like that or by clicking on the restore/maximize button at the top right of the window, firefox stopped responding and Firefox Nightly (Not Responding) was shown in the top bar. The window colours faded as happens when a Plasma window is unresponsive. I've seen this from 71.0a1 (2019-10-01) to 72.a1 (2019-11-02) on Wayland with layers.acceleration.force-enabled=true stop responding like this each of 10+ times, and I hadn't seen that before with 71.0a1 or earlier on Wayland with layers.acceleration.force-enabled=false. I've had to close firefox when it stopped responding like that because it didn't start responding again. I reported this originally at https://bugzilla.mozilla.org/show_bug.cgi?id=1584845#c9 I'm reporting the issue in a new bug since it's still happening and so it doesn't get missed.

Expected results:

Firefox should have kept responding normally after resizing it.

Summary: [Wayland/KDE] Nightly 71.0a1-72.0a2 on Wayland stopped responding after resizing on Plasma on Wayland → [Wayland/KDE] Nightly 71.0a1-72.0a1 on Wayland stopped responding after resizing on Plasma on Wayland

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
Attached file gdb.txt

I'm not sure if this helps but here's gdb attached to a stuck firefox process. I used a new profile opened to about:blank and tried to reproduce the issue as quickly as possible, immediately re-sizing the window after the page had loaded. This causes the window to lock up, which I think Kwin detects because the colour of the window changes to a semi-transparent grey with the title bar displaying "not responding".

I'm quoting what I think are the relevant lines below:

#0 0x00007ffff7f857b5 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
#1 0x00005555555cd25f in mozilla::detail::ConditionVariableImpl::wait(mozilla::detail::MutexImpl&) (this=0x7fffdec08540, lock=...)
at /var/tmp/portage/www-client/firefox-99999999/work/firefox-561365-e7d2e0642ae0/mozglue/misc/ConditionVariable_posix.cpp:109
#2 0x00005555555cd25f in mozilla::detail::ConditionVariableImpl::wait_for(mozilla::detail::MutexImpl&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (this=0x7fffdec08540, lock=..., a_rel_time=...)
at /var/tmp/portage/www-client/firefox-99999999/work/firefox-561365-e7d2e0642ae0/mozglue/misc/ConditionVariable_posix.cpp:116
#3 0x00007ffff11d7c4b in mozilla::OffTheBooksCondVar::Wait(mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>)
(this=<optimized out>, aDuration=...)
at /var/tmp/portage/www-client/firefox-99999999/work/firefox-561365-e7d2e0642ae0/ff/dist/include/mozilla/CondVar.h:64
#4 0x00007ffff11d7c4b in mozilla::Monitor::Wait(mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>)
(this=<optimized out>, aDuration=...)
at /var/tmp/portage/www-client/firefox-99999999/work/firefox-561365-e7d2e0642ae0/ff/dist/include/mozilla/Monitor.h:37
#5 0x00007ffff11d7c4b in mozilla::ipc::MessageChannel::WaitForSyncNotify(bool) (this=<optimized out>)
at /var/tmp/portage/www-client/firefox-99999999/work/firefox-561365-e7d2e0642ae0/ipc/glue/MessageChannel.cpp:2397
#6 0x00007ffff11d7c4b in mozilla::ipc::MessageChannel::Send(IPC::Message*, IPC::Message*)
(this=0x7fffdec1b900, aMsg=<optimized out>, aReply=0x7fffffffab28)
at /var/tmp/portage/www-client/firefox-99999999/work/firefox-561365-e7d2e0642ae0/ipc/glue/MessageChannel.cpp:1563
#7 0x00007ffff11d7c4b in mozilla::ipc::IProtocol::ChannelSend(IPC::Message*, IPC::Message*)
(this=<optimized out>, aMsg=<optimized out>, aReply=0x7fffffffab28)
at /var/tmp/portage/www-client/firefox-99999999/work/firefox-561365-e7d2e0642ae0/ipc/glue/ProtocolUtils.cpp:488
#8 0x00007ffff12636e9 in mozilla::layers::PCompositorBridgeChild::SendFlushRendering() (this=0x7fffdec1d000) at PCompositorBridgeChild.cpp:1081
#9 0x00007ffff3490b2c in nsViewManager::Refresh(nsView*, mozilla::gfx::IntRegionTyped<mozilla::LayoutDevicePixel> const&) (this=<optimized out>, aView=0x7fffe0cf5200, aRegion=...) at /var/tmp/portage/www-client/firefox-99999999/work/firefox-561365-e7d2e0642ae0/view/nsViewManager.cpp:336
#10 0x00007ffff3490b2c in nsViewManager::PaintWindow(nsIWidget*, mozilla::gfx::IntRegionTyped<mozilla::LayoutDevicePixel> const&) (this=<optimized out>, aWidget=<optimized out>, aRegion=...) at /var/tmp/portage/www-client/firefox-99999999/work/firefox-561365-e7d2e0642ae0/view/nsViewManager.cpp:692
#11 0x00007ffff3490b2c in nsView::PaintWindow(nsIWidget*, mozilla::gfx::IntRegionTyped<mozilla::LayoutDevicePixel>) (this=<optimized out>, aWidget=<optimized out>, aRegion=...) at /var/tmp/portage/www-client/firefox-99999999/work/firefox-561365-e7d2e0642ae0/view/nsView.cpp:989
#12 0x00007ffff34f1ae7 in nsWindow::OnExposeEvent(_cairo*) (this=0x7fffe986c400, cr=0x7fffdffd9000) at /var/tmp/portage/www-client/firefox-99999999/work/firefox-561365-e7d2e0642ae0/widget/gtk/nsWindow.cpp:2310
#13 0x00007ffff34f1ae7 in draw_window_of_widget(_GtkWidget*, _GdkWindow*, _cairo*) (widget=0x7ffff77b6bb0, aWindow=0x7ffff77b6de0, cr=0x7fffdffd9000) at /var/tmp/portage/www-client/firefox-99999999/work/firefox-561365-e7d2e0642ae0/widget/gtk/nsWindow.cpp:5720
#14 0x00007ffff34ee3b0 in expose_event_cb(_GtkWidget*, _cairo*) (widget=0x7ffff77b6bb0, cr=0x0) at /var/tmp/portage/www-client/firefox-99999999/work/firefox-561365-e7d2e0642ae0/widget/gtk/nsWindow.cpp:5741

Can confirm the issue with amdgpu/radeonsi mesa 19.2.6 on latest Nightly.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: wayland-kde
No longer blocks: wayland

(In reply to Johannes Pfrang [:johnp] from comment #3)

Can confirm the issue with amdgpu/radeonsi mesa 19.2.6 on latest Nightly.

Also with intel GPU here...

I'm experiencing the same issue with an intel GPU. I observe

...
 -> wl_display@1.sync(new id wl_callback@76)
wl_display@1.delete_id(76)
wl_callback@76.done(1187)
 -> wl_display@1.sync(new id wl_callback@76)
wl_display@1.delete_id(^C76)
wl_callback@76.done(1187)
 -> wl_display@1.sync(new id wl_callback@76)
wl_display@1.delete_id(76)
wl_callback@76.done(1187)
...

during the freeze when I start firefox with MOZ_ENABLE_WAYLAND=1 WAYLAND_DEBUG=1 firefox.

This bug should be fixed by https://phabricator.kde.org/D28145.

(In reply to Vlad Zahorodnii [:zzag] from comment #6)

This bug should be fixed by https://phabricator.kde.org/D28145.

Thanks Vlad. Firefox Nightly 76.0a1 (2020-4-1) on Wayland resizes properly and remains responsive on Plasma 5.18.4 on Wayland with KF 5.68.0, Qt 5.13.2, where as it didn't on Plasma 5.18.3.

Closing, Thanks.(In reply to Vlad Zahorodnii [:zzag] from comment #6)

This bug should be fixed by https://phabricator.kde.org/D28145.

Closing, Thanks.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INVALID
Resolution: INVALID → MOVED

For me if I have wayland support enabled in Firefox 75, the Firefox UI gets buggy, also happens with Firefox 76 beta. The firefox menu doesn't work properly and all other sorts of weird issues.
Apart from the binary provided by mozilla, my self compiled firefox is even worse.
Gentoo, Linux 5.6.2, KDE 5.17.5

(In reply to rickard from comment #9)

For me if I have wayland support enabled in Firefox 75, the Firefox UI gets buggy, also happens with Firefox 76 beta. The firefox menu doesn't work properly and all other sorts of weird issues.
Apart from the binary provided by mozilla, my self compiled firefox is even worse.
Gentoo, Linux 5.6.2, KDE 5.17.5

Wayland is under rapid development, you need something more recent than 5.17.5. see https://bugzilla.mozilla.org/show_bug.cgi?id=1593478#c7

Updated to KDE 5.18.4, basically the same issue with Plasma on Wayland and MOZ_ENABLE_WAYLAND=1
Also tried with a new profile, no difference.

The UI and webpages is not being rendered/updated correctly, it doesn't entirely lock the browser. It updates when there are some other part of the UI that's being changed, like clicking on a menu...

Can you try to enable webrender? Manually set the gfx.webrender.enabled or gfx.webrender.all pref to true. You can do this from about:config, and it requires restarting the browser to take effect.
Thanks.

Flags: needinfo?(rickard)

No difference. As soon as I enable wayland support, things go bad. Works fine in x11 mode.

Flags: needinfo?(rickard)

I can confirm Plasma 5.18.4 and FF Nightly work correctly on Wayland with Webrender while FF stable with OGL renders only a black rectangle instead of the main window.

(In reply to mthw0 from comment #14)

I can confirm Plasma 5.18.4 and FF Nightly work correctly on Wayland with Webrender while FF stable with OGL renders only a black rectangle instead of the main window.

Correct, Firefox 77 nightly seems to work on Wayland with both Webrenderer and OGL.
Firefox 75 and 76 beta does not work.

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