1452561 - WebRTC screenshare of window crashes tab if you maximise the shared window on Mac OSX

Status: RESOLVED DUPLICATE of bug 1453740

(Core :: WebRTC, defect, P2)

Description

[Hugh Livingstone]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

You can use the following website to reproduce this issue:
 - https://janus.conf.meetecho.com/screensharingtest.html

Tested On

This crash does not occur on Windows 10, only Mac OSX.  

The crash occurs with the following
High Sierra
Firefox Nightly 61.0a1 (2018-04-08) (64-bit)
FF stable 60.0b10 (64-bit)

General Steps
1. Create a GetUserMediaRequest with mediaSource: "window".
2. Select an application from the GUM dialog
3. Once the video is being shared, click the green maximise button on the shared application. 

The browser will either completely close or crash the tab with an the normal crash page asking if you want to report it.

Steps - for reproducing on https://janus.conf.meetecho.com/screensharingtest.html
1. Click the Start button
2. Insert a name for the session and click "Share your screen"
3. Select "Pick a window"
4. Maximise the selected window and it will crash

Notes:

If I run the following demo which just does GUM and does not attach the MediaStream to a WebRTC peerconnection, I can maximise without crashing.
 - https://www.webrtc-experiment.com/getScreenId/

Comment 1

[Hugh Livingstone]

Sorry The Tested on - 60.0b10 was the beta version.
The result is the same on FF stable 59.0.2 (64-bit).

Comment 2

[Marcia Knous [:marcia]]

Hugh: Can you please type about:crashes in the URL bar and paste the crash report ID? Thanks.

Comment 3

[Hugh Livingstone]

The crash link is:
https://crash-stats.mozilla.com/report/index/4781cc4b-31b0-44ba-9e0d-ee0930180406

Comment 4

[Marcia Knous [:marcia]]

Adding crash signature and moving component.

Comment 5

[Michael Froman [:mjf]]

I can confirm this on 10.11.6 (El Cap) running 61.0a1 (2018-04-10) (64-bit).

Comment 6

[Paul Adenot (:padenot)]

I can repro as well on OSX High Sierra (100% of the time):

    frame #0: 0x000000010e593495 libmozglue.dylib`mozalloc_abort(msg=<unavailable>) at mozalloc_abort.cpp:34 [opt]
    frame #1: 0x000000010e5934c0 libmozglue.dylib`::abort() at mozalloc_abort.cpp:81 [opt]
    frame #2: 0x0000000103536eb5 XUL`rtc::FatalMessage::~FatalMessage(this=<unavailable>) at checks.cc:109 [opt]
    frame #3: 0x0000000103535ca9 XUL`rtc::FatalMessage::~FatalMessage(this=<unavailable>) at checks.cc:102 [opt]
  * frame #4: 0x00000001036a4bda XUL`webrtc::ViEEncoder::ReconfigureEncoder(this=<unavailable>) at vie_encoder.cc:424 [opt]
    frame #5: 0x00000001036a5040 XUL`webrtc::ViEEncoder::EncodeVideoFrame(this=0x000000014ccfd000, video_frame=<unavailable>, time_when_posted_in_ms=30435906) at vie_encoder.cc:553 [opt]
    frame #6: 0x00000001036a690d XUL`webrtc::ViEEncoder::EncodeTask::Run(this=0x000000011c9d0150) at vie_encoder.cc:105 [opt]
    frame #7: 0x000000010353a214 XUL`rtc::TaskQueue::TaskContext::RunTask(context=0x00000001120fa6e0) at task_queue_gcd.cc:53 [opt]
    frame #8: 0x00007fff75042e08 libdispatch.dylib`_dispatch_client_callout + 8
    frame #9: 0x00007fff75057267 libdispatch.dylib`_dispatch_queue_serial_drain + 635
    frame #10: 0x00007fff7504a1b6 libdispatch.dylib`_dispatch_queue_invoke + 373
    frame #11: 0x00007fff75057f5d libdispatch.dylib`_dispatch_root_queue_drain_deferred_wlh + 332
    frame #12: 0x00007fff7505bd71 libdispatch.dylib`_dispatch_workloop_worker_thread + 880
    frame #13: 0x00007fff75393fd2 libsystem_pthread.dylib`_pthread_wqthread + 980
    frame #14: 0x00007fff75393be9 libsystem_pthread.dylib`start_wqthread + 13

last_frame_info_->width is 1, same for the height in frame #4, pretty fishy.

Comment 7

[Dan Minor [:dminor]]

A width/height of 1 will cause the vp8 codec to fail to initialize. I have a workaround for that at Bug 1453740. Not sure why we're getting small widths and heights when we maximize the window. If we're lucky, that's a transient state and we'll settle on the proper resolution. If not, I'll have to have a look at the window sharing code.

Comment 8

[Dan Minor [:dminor]]

With the patch from Bug 1453740 applied this no longer reproduces. Additionally, it appears the 1x1 resolution is a transient state as the shared window goes black for the other participants for maybe half a second and then the appears again maximized.

Comment 9

[Dan Minor [:dminor]]

In my testing, the fix for Bug 1453740 also fixes this, so I'm going to close this as a duplicate of that bug. If anyone hits this again, please re-open and I'll investigate it further.