The entire system crashes when using the seekbar of an YouTube video in Firefox

Did someone ever experience this issue before? When I’m watching an YouTube video and use the seek bar, the entire system freezes. Sometimes the display turns black and other times I can still see the display contents, but I can’t interact with anything; not even switching ttys works. The crash doesn’t happen consistently though. Also, this seems to happen only when I’m using a bluetooth headset.

I have no idea where to find the proper logs to find more about what’s going on. Gnome-shell logs don’t show anything; the ABRT app also doesn’t show anything; same thing for the logs entries in GNOME logs.

The crash happened again today 10 minutes ago… :frowning:

I’m using:

  • Firefox 124.0 (Flatpak from Flathub with the MOZ_ENABLE_WAYLAND env variable)
  • Fedora 39 Workstation
  • GNOME 45.4
  • Wayland
  • Shell extensions: GSConnect (the issue already happened without extensions IIRC)

Edit: sometimes when using the seekbar, the bluetooth codec profile switches “by itself” and I need to go to Settings > Sound and change the codec profile again, otherwise the audio keeps playing in very low quality. Other times, one side of the headset stops working and I have to reboot the system, because repairing the device doesn’t fix this issue. It seems that the root cause of the system crash might be related to the bluetooth stack.

I’d try launching firefox from a terminal window and see if any interesting notices are displayed when the error occurs.

Pretty much any YouTube activity causes multiple failures now using Xorg or Wayland constant tab crashes in Firefox or Chrome. I have many gnome crash messages as well.

My system has become almost un-usable.

Without a meaningful error message, we can only guess as to what is wrong. I would guess that it is due to a video codec and/or a video driver, but that is just a guess.

Will follow-up with logs but I’m out on the road at the moment

A quick test that can help to narrow things down would be to create a new user account on your system, sign in with that, and see if the problem persists. If not, the problem is likely something in your home directory. It is possible to install things like python libraries under your home directory in a way that other system utilities will pick them up and cause severe failures like what you are describing.

If you can leave journalctl -f running in a terminal (perhaps on a secondary monitor or in a SSH session connected from a separate computer), that would be a good way to “monitor” your logs as an event occurs.

1 Like

just going to post here the problems as they arise.

Apr 03 08:12:21 marks-linux-desktop abrt-server[8577]: Unsupported container technology
Apr 03 08:12:21 marks-linux-desktop abrt-server[8577]: Lock file ‘.lock’ was locked by process 8580, but it crashed?
Apr 03 08:12:21 marks-linux-desktop abrt-server[8577]: Error: No segments found in coredump ‘./coredump’
Apr 03 08:12:21 marks-linux-desktop abrt-server[8577]: Can’t open file ‘core_backtrace’ for reading: No such file or directory
Apr 03 08:12:21 marks-linux-desktop abrt-applet[3820]: g_app_info_should_show: assertion ‘G_IS_APP_INFO (appinfo)’ failed
Apr 03 08:12:21 marks-linux-desktop abrt-notification[8648]: [🡕] Process 8307 (postman) crashed in ??()