fix(mac): expose getDisplayMedia() permission decision handler

[pewsheen]

Related issue: #1195

Temporary fix for the issue. Needs to find the affected range in the future.

[FabianLars]

Suggested change

	(14, 0, _) => {
	// Do not suppress media request on 14.0:
	// https://github.com/tauri-apps/wry/issues/1101
	}
	(14, 0, _) | (14, 1, _) => {
	// Do not suppress media request on 14.0 & 14.1:
	// https://github.com/tauri-apps/wry/issues/1101
	}

#1195 (comment)

[FabianLars]

(just blocking this because of ongoing discussion in #1195)

[pewsheen]

@FabianLars Your private API (or maybe just not document yet?) hint is mega helpful

After I read some WebKit source code
https://github.com/WebKit/WebKit/blob/b7a7805ab3a2a1b719af3112657934e837ee3df5/Source/WebKit/UIProcess/Cocoa/UIDelegate.mm#L1260

bool respondsToRequestMediaCapturePermission = [delegate respondsToSelector:@selector(webView:requestMediaCapturePermissionForOrigin:initiatedByFrame:type:decisionHandler:)];
bool respondsToRequestUserMediaAuthorizationForDevices = [delegate respondsToSelector:@selector(_webView:requestUserMediaAuthorizationForDevices:url:mainFrameURL:decisionHandler:)];
bool respondsToRequestDisplayCapturePermissionForOrigin = [delegate respondsToSelector:@selector(_webView:requestDisplayCapturePermissionForOrigin:initiatedByFrame:withSystemAudio:decisionHandler:)];

I guess they are using _webView:requestDisplayCapturePermissionForOrigin:initiatedByFrame:withSystemAudio:decisionHandler: for getDisplayMedia and yes!

The reason why it's not working on your commit is because the typo LOL

- _webView:requestDisplayCapturePermissionForSecurityOrigin:initiatedByFrame:withSystemAudio:decisionHandler:
+ _webView:requestDisplayCapturePermissionForOrigin:initiatedByFrame:withSystemAudio:decisionHandler:

But it's still not showing the window / screen select panel, just window OR screen.

[FabianLars]

nooo, not a freaking typo, I just can't 😂

[pewsheen]

Just update the implementation, will expose a closure and let them pick the decision

[pewsheen]

Maybe it can just store the decision instead of a closure, since there's only a capture type parameter?

[FabianLars]

Suggested change

	pub(crate) fn drop_decision_hanlder(webview: *mut Object) {
	pub(crate) fn drop_decision_handler(webview: *mut Object) {

(the usages of this function have the same typo)

[FabianLars]

Maybe it can just store the decision instead of a closure, since there's only a capture type parameter?

I'm not 100% sure i really understand. When we use a variable only the developer could decide right? The good thing about the handler is that wkwebview will call that itself and then the dev can implement something that will let the actual app user decide if they want a screen or window prompt. I don't see how we could mimic this with just a variable.

[pewsheen]

Maybe it can just store the decision instead of a closure, since there's only a capture type parameter?

I'm not 100% sure i really understand. When we use a variable only the developer could decide right? The good thing about the handler is that wkwebview will call that itself and then the dev can implement something that will let the actual app user decide if they want a screen or window prompt. I don't see how we could mimic this with just a variable.

In this case, the developer will need to implement something like a prompt to let the user choose to capture a screen or a window and call a setter like set_capture_target(Window or Screen), and then call the getDisplayMedia().

Closure is good and may not need an extra set step like the variable approach. But I think it will be a bit more complicated managing the lifetime and ownership when implementing logic inside the closure.

[FabianLars]

Hmm, another problem that comes to mind is that this makes it harder for use cases where you load external websites that you don't control since then you don't really know when you ask the user what they want to share. I still think this is still a bit of a problem even if it's your website because then you have to communicate between js and rust to know when to prompt the user.

Closure is good and may not need an extra set step like the variable approach. But I think it will be a bit more complicated managing the lifetime and ownership when implementing logic inside the closure.

Hmm, yeah that could be a problem. I thought/hoped that the main thing to do here would be to simply call rfd in that closure and leave it at that 🤔