Bug 258631

Summary: [MacOS, Safari | M1] Screen sharing fails and the user cannot share the screen if the user waits for the blue screen overlay to appear after permission to share the screen has been granted
Product: WebKit Reporter: Madara Freimane <madara.freimane>
Component: WebRTCAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: eric.carlson, jer.noble, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: Safari 16   
Hardware: Mac (Apple Silicon)   
OS: macOS 13   

Description Madara Freimane 2023-06-28 11:29:14 PDT 
Summary:
Screen sharing fails and the User cannot share the screen anymore if the User waits for the blue screen overlay to appear after permission to share the screen has been granted. The bug is observed on MacBook devices with M1 chip.

Tested devices and browsers:
The bug IS reproducible on:
- MacBook Pro (M1, 2020, macOS Ventura 13.4) and Safari (V16.5)
- MacBook Pro (M1, 2020, macOS Sonoma 14 Beta) and Safari (V17, (19616.1.14.11.11))

The bug IS NOT reproducible on:
- MacBook Pro (M1, 2020, macOS Ventura 13.4) and Google Chrome (V114.0.5735.133)
- MacBook Pro (Intel, 2020, macOS Ventura 13.4) and Safari (V16.5 (18615.2.9.11.4))


Use case:
Precondition:
Safari browser opened
The User has an active WebRTC call

Steps:
1. User clicks on the button "Share screen"
2. User clicks on the button "Allow to Share Screen" that appears on the pop-up
3. User waits and does not move the cursor for ~1min

Actual result:
The blue screen sharing overlay does not appear and if the User wants to share again the screen, it is not possible (seems that the User must grant permission again in order to share the screen although permission was granted already).

Expected result:
User should be able to share screen every time when click on the "Start sharing your screen" button, screen sharing options should appear

Reproducibility:
90%

Notes:
Also observed new behavior / similar to this one with Sonoma 14, Safari (V17), if the User clicks on the "Share screen" button, then clicks on the "Cancel" button on the pop-up that comes from the browser side and not on the "Allow to Share Screen". The process is canceled which is OK, but if the User wants to share again the screen, it is not possible, and also not possible if the User re-joins the webRTC call. Users can share the screen only if refresh the page / close and open Safari.

Sysdiagnostics file added:
https://drive.google.com/file/d/1w8JX4vPc7_o9IeMfbOq3hnnQoljlqh01/view?usp=sharing
Comment 1 Radar WebKit Bug Importer 2023-07-03 07:23:44 PDT 
<rdar://problem/111685703>
Comment 2 Eric Carlson 2023-07-03 07:24:02 PDT 
> Also observed new behavior / similar to this one with Sonoma 14, Safari (V17), if the User clicks on the "Share screen" button, then clicks on the "Cancel" button on the pop-up that comes from the browser side and not on the "Allow to Share Screen". The process is canceled which is OK, but if the User wants to share again the screen, it is not possible, and also not possible if the User re-joins the webRTC call. Users can share the screen only if refresh the page / close and open Safari.

If the user denies a request to capture audio, video, or screen, they are not prompted again until the page is reloaded. This is to prevent a page from prompting the user over and over.
Comment 3 Madara Freimane 2024-04-23 05:33:05 PDT 
Use case - User tries to share the screen, but is not able to do it, the button “Share screen” does not work for a while. If User tries to re-share the screen, the option still does not work, sometimes there is a need to rejoin a WebRTC call to be able to share the screen.
Seems that this problem is only on macOS 13.x and I am not able to reproduce the exact problem with macOS 14.4.1. Can you please confirm that there is a fix for the described problem with macOS 14.x?

A new sysdiagnostics file added (bug reproduced - Apr 23, 2024, at 14:43:00):
https://drive.google.com/file/d/1pgrkxvR5E8y32Kpd0c4fvCxlgotUAQnH/view?usp=sharing 

Bug is reproducible on:
- MacBook Air (M1, 2020, macOS 13.4 (22F66)) and Safari (V16.5 (18615.2.9.11.4))

Bug is not reproducible on:
- MacBook Pro (M1, 2020, macOS 14.4.1 (23E224)) and Safari (V17.4.1 (19618.1.15.11.14))