Closed Bug 1616527 Opened 2 years ago Closed 2 years ago

Crash when device is plugged or unplugged after page refresh

Categories

(Core :: WebRTC: Audio/Video, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla75
Tracking Status
firefox75 --- verified

People

(Reporter: achronop, Assigned: achronop)

Details

Attachments

(1 file)

I am reproducing it in a local debug build but not in Nightly, probably due to different timing.

Steps:
Plug in an external camera
Use the following fiddle: https://jsfiddle.net/jib1/LbtxeLvw/
Press the "Start Camera!" button and choose any device.
Refresh the page.
Unplug the external camera.

Result:
Window is crashing

When a page navigates away for example after a refresh, the collection of MediaDevices instance can take several seconds. If MediaManager is alive and a device change event arrives in it, the active instance of MediaDevices will be notified. Currently, the notification assert-crash when the window is not valid anymore. However, this is a valid scenario and depends on the cycle collection timing so the assert can be removed and the notification event can abort early and do nothing.

Pushed by achronopoulos@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6dfa3fdef59d
Stop asserting on device change event when the window has navigated away. r=jib
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla75
Flags: qe-verify+

I was able to get a tab crash using an old nightly debug build from 2020-02-17 and following the steps from comment 0. Verified that using latest Nightly 76 and Firefox 75.0b7 debug builds I did not get the crash across platforms (Ubuntu 18.04 64bit, macOS 10.15 and Windows 10 64bit).

I did encounter a browser shutdown (or sometimes a browser hang) when clicking Start Camera! and then Allow on the permission notification using de 75.0b7 debug build and only on Windows 10 64bit. Is this something we should worry about?

Flags: needinfo?(achronop)

Well, it depends. If you can reproduce in the latest Nightly you must open a bug about it. If you can reproduce reliable but only on beta it would be nice if you can run mozregression and find what has fixed it, in case we can provide an uplift. If you reproduced just once and it hasn't reproduced again I don't think we can do much about it.

Flags: needinfo?(achronop)

(In reply to Alex Chronopoulos [:achronop] from comment #5)

Well, it depends. If you can reproduce in the latest Nightly you must open a bug about it. If you can reproduce reliable but only on beta it would be nice if you can run mozregression and find what has fixed it, in case we can provide an uplift. If you reproduced just once and it hasn't reproduced again I don't think we can do much about it.

Turns out that indeed I can reliably reproduce on Windows 10 64bit with latest Nightly debug build (https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=2abd352490a4bf2e3a9118b154c0e351c0bad314). I logged bug 1624899 for that issue.

I'll go ahead and close this one since the scenario that was fixed here are indeed fixed for me across platforms.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.