[macOS] Private API usage

[rajivshah3]

The commit introducing clipboard access uses private APIs for its macOS implementation. This can result in App Review rejection for apps submitted to the Mac App Store. We should try to find another way to do this without using private APIs.

webview/webview.h

Lines 631 to 638 in 9444582

	objc_msgSend(objc_msgSend(config, "preferences"_sel),
	"setValue:forKey:"_sel,
	objc_msgSend("NSNumber"_cls, "numberWithBool:"_sel, 1),
	"javaScriptCanAccessClipboard"_str);
	objc_msgSend(objc_msgSend(config, "preferences"_sel),
	"setValue:forKey:"_sel,
	objc_msgSend("NSNumber"_cls, "numberWithBool:"_sel, 1),
	"DOMPasteAllowed"_str);

https://github.com/WebKit/webkit/blob/950143da027e80924b4bb86defa8a3f21fd3fb1e/Source/WebKitLegacy/mac/WebView/WebPreferencesPrivate.h#L226

[rajivshah3]

Possible solution (haven't tried yet): #99 (comment)

[nothingismagick]

Just as a comment from the bleachers: We absolutely MUST not use private APIs in webview core. The problem is that it is a reason for the appstore to block apps made with webview. It is more preferable to find a way to do this without private APIs, but barring that we will have to make it VERY clear that its inclusion is likely to be a reason for not getting your app accepted. If that is down to the library you are using, it is likely to not only be very frustrating, but also a massive problem long term.

[abemedia]

My bad I didn't realise the app store issue...
I do think clipboard access is pretty important though so how we go for the app menu implementation?

Could probably make some time to have a bash at it tomorrow.

[abemedia]

Was just thinking... Allowing pasting through the use of menu items doesn't give us navigator.clipboard access.
For my use-case this was necessary so how about if we add a function like WebView.SetClipboardAccess(bool) so users can opt-in to this? There's a whole load of widely used apps out there that do actually use private APIs (e.g. VSCode)...

[nothingismagick]

That's a good idea @abemedia - what do you think about opting in @rajivshah3 & @lucasfernog ?

[lucasfernog]

Rajiv knows more about it but I think we can't even compile private APIs so it should be a flag switch?

[abemedia]

Rajiv knows more about it but I think we can't even compile private APIs so it should be a flag switch?

Even if they are never called?

[sgg]

Does "clipboard access from JS" cover something more than being able to use the clipboard period? I added quick and dirty support for clipboard access from macOS in the webview Rust bindings since I needed that for a project.

Here is a diff. If it's in line with what folks are looking for I'm happy to clean it up and put up a PR.

[abemedia]

What about navigator.clipboard access in JS though?

I do think that having the edit menu makes sense also, however there was a PR for this a while ago which @zserge rejected (#237). Maybe this could also be opt-in?

Slightly off-topic but I'd actually love to see a cross-platform solution for adding custom menus as mentioned by @zserge in the PR above.

[rajivshah3]

Even if they are never called?

Apple's process for checking for private APIs is a secret so I'm not entirely sure whether they use static or dynamic/runtime analysis. To be on the safe side, I'd say they shouldn't be present in the binary at all (so that they're not picked up by static analysis). We could have a flag (for example, TARGET_MAS, short for Mac App Store) that users can define which prevents any webview APIs that use private macOS APIs from being compiled.

For example:

#if !defined(TARGET_MAS)
void function_that_does_stuff () {
  _PrivateApiThatShouldntBeCalled(param1, param2);
}
#endif 

[abemedia]

I'm happy to make a quick PR, however I was wondering if it makes more sense to have this opt-in or opt-out?
Because if the webview is being used to access other websites not under the control of the app creator I guess clipboard access can be a security concern...

We could have a flag like ENABLE_CLIPBOARD and have clipboard access for all platforms disabled by default.

[abemedia]

Any thoughts on this guys?