1753990 - Wireframe collection being enabled causes parent process crashes when going through WebRTC permission popups for Google Meet

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

STR:

1. In about:config, set browser.history.collectWireframes to true
2. Visit https://meet.new
3. Log in to Google if necessary
4. Wait for the WebRTC camera / microphone permission popup to appear
5. Click "Allow" to allow Google Meet access to camera / microphone devices

ER:

Google Meet should load with the camera and microphone shared. You should be in some kind of Google Meet lobby.

AR:

Parent process crash.

Crash report: https://crash-stats.mozilla.org/report/index/e2b9981f-93fc-4a34-a4f5-8c4c10220207

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Digging into this a bit, it looks like the sometimes-not-visible chrome://browser/content/webrtcIndicator.xhtml window is the one we're attempting to collect the wireframe for when we crash.

We only ever want to collect wireframes for the content area, so that's probably our first layer of defense against this particular crash: only allow collecting wireframes for the content area.

The second layer of defense is adding a null check to ensure we're not trying to build a displaylist for a null frame.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1753990 - Add a null-check for root frames when collecting wireframes. r?emilio!

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1753990 - Only collect wireframes for top content BrowsingContexts. r?emilio!

Depends on D138049

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8c7d39fffd27
Add a null-check for root frames when collecting wireframes. r=emilio
https://hg.mozilla.org/integration/autoland/rev/bdf7b202c658
Only collect wireframes for top content BrowsingContexts. r=emilio

Comment 5

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/8c7d39fffd27
https://hg.mozilla.org/mozilla-central/rev/bdf7b202c658

Comment 6

[Cristian Baica [:cbaica], Release Desktop QA]

I've managed to reproduce the issue using Fx99.0a1.
The issue is verified fixed using Fx100.0a1 and Fx99.0b7 on Windows 10 and Ubuntu 20.04. Firefox no longer crashed when having the pref enabled and clicking the 'Allow' button.