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

Steps to reproduce:

Install a new Firefox Nightly on Arch Linux. All website is working fine but YouTube crashes the whole system.

Actual results:

All video plays on YouTube crashes and the whole system is frozen

System: Arch Linux Latest
Firefox Nightly Version: Since 103 cdd6f971

I use mozregression and tested all versions from May 30 to June 2

 1:02.23 INFO: Downloading build from: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/WVjA21VLQ-yosyyliafHRQ/runs/0/artifacts/public%2Fbuild%2Ftarget.tar.bz2
===== Downloaded 100% =====
 1:11.54 INFO: Running autoland build built on 2022-06-01 21:43:22.040000, revision cdd6f971
 1:13.61 WARNING: Skipping build 14f66d865986: Unable to find build info using the taskcluster route 'gecko.v2.autoland.shippable.revision.14f66d8659860680e4b3ee49ce5d45ba1960805f.firefox.linux64-opt'
 1:17.34 INFO: Launching /tmp/tmpq8zqoym2/firefox/firefox
 1:17.34 INFO: Application command: /tmp/tmpq8zqoym2/firefox/firefox -profile /tmp/tmpd5shv7as.mozrunner
 1:17.34 INFO: application_buildid: 20220601201300
 1:17.34 INFO: application_changeset: cdd6f971633bf9b3ede231f0819a9912421460e1
 1:17.34 INFO: application_name: Firefox
 1:17.34 INFO: application_repository: https://hg.mozilla.org/integration/autoland
 1:17.34 INFO: application_version: 103.0a1
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): bad
 1:20.12 INFO: Narrowed integration regression window from [8ab0d8a3, d230cd99] (4 builds) to [8ab0d8a3, cdd6f971] (2 builds) (~1 steps left)
 1:20.12 INFO: No more integration revisions, bisection finished.
 1:20.12 INFO: Last good revision: 8ab0d8a38dd3684021c38422d73381afc239a27b
 1:20.12 INFO: First bad revision: cdd6f971633bf9b3ede231f0819a9912421460e1
 1:20.12 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8ab0d8a38dd3684021c38422d73381afc239a27b&tochange=cdd6f971633bf9b3ede231f0819a9912421460e1

The last working version is 8ab0d8a3

Expected results:

Maybe something is wrong between 8ab0d8a3 and cdd6f971

My desktop is KDE Plasma with Arch Linux latest version

Hardware and OS I use:

                 .o+`                    -----------------
                `ooo/                    OS: Arch Linux [x86_64]
               `+oooo:                   Host: Z690M-ITX/ax
              `+oooooo:                  Kernel: 5.18.10-arch1-1
              -+oooooo+:                 Uptime: 5 mins
            `/:-:++oooo+:                Packages: 1438 (pacman)
           `/++++/+++++++:               Shell: zsh 5.9
          `/++++++++++++++:              Resolution: 2560x1440 @ 120Hz
         `/+++ooooooooooooo/`            DE: KDE Plasma 5.25.3
        ./ooosssso++osssssso+`           WM: KWin (X11)
       .oossssso-````/ossssss+`          WM Theme: Breeze
      -osssssso.      :ssssssso.         Theme: Breeze (Dark) [Plasma], Breeze [GTK2/3]
     :osssssss/        osssso+++.        Icons: breeze-dark [Plasma], breeze-dark [GTK2/3/4]
    /ossssssss/        +ssssooo/-        Font: Noto Sans (10pt) [Plasma], Noto Sans (10pt) [GTK2/3/4]
  `/ossssso+/:-        -:/+osssso+-      Cursor: breeze (24px)
 `+sso+:-`                 `.-/+oso:     Terminal: konsole
`++:.                           `-/+/    CPU: 12th Gen Intel Core i7-12700K (20) 
.`                                 `/    GPU: AMD ATI Radeon RX 6400 / 6500 XT
                                         Memory: 3642MiB / 64065MiB (5%)
                                         Disk (/): 99GiB / 915GiB (10%)
                                         Locale: en_US.UTF-8

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Setting Regressed by field after analyzing regression range found by mozregression in comment #0.

Set release status flags based on info from the regressing bug 1766546

:Jamie, since you are the author of the regressor, bug 1766546, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Eitan, can you reproduce this on Linux? I really don't see how the SetCaretOffset patch could have caused this. Regardless of the cache, on Linux, the code does exactly as it always did; it's just moved to the base class.

After block VP8, VP9 and AV1 codecs by using this plugin https://github.com/alextrv/enhanced-h264ify and it's working fine now.

If we enabled VP8, VP9 and AV1 codecs, my Firefox Nightly will be crashed.

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Do have any crash report IDs in about:crashes that you could share?

I don't have any ideas if the crash report works

bp-5f0558fb-2973-4a90-948c-9f1d30220714
bp-3fd01d67-697c-4ece-a1e0-51a0d0220619

Those crash reports don't seem to have good symbols, which makes it pretty hard to get a feel for the problem :(. That said, comment 7 makes me wonder if maybe there's something sandboxing-related in play here? Jed, any thoughts on further steps we could take to try to diagnose the culprit here?

Given the report that “the whole system is frozen” I wonder if the problem is buggy GPU drivers, but there's a simple way to rule out the RDD sandbox: run with MOZ_DISABLE_RDD_SANDBOX=1 in the environment.

Also, turning off the RDD process with media.rdd-process.enabled (in about:config) should disable VA-API (hardware acceleration), so that's another useful data point.

Set release status flags based on info from the regressing bug 1766546

Can't reproduce, and I'm not convinced bug 1766546 is the culprit.

showfom, do you still see it? In such case please attach your about:support page content.
Thanks.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:stransky, since the bug has recent activity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit auto_nag documentation.