blckngm / webview2

Rust bindings for WebView2
MIT License
73 stars 12 forks source link

Use experimental features? #12

Open WilliamVenner opened 3 years ago

WilliamVenner commented 3 years ago

Hi,

Thanks for the fantastic bindings. I had a shot at trying to implement experimental features from the Webview2 SDK into these bindings but it seems that idl files and the parser used here aren't as simple as I thought.

Would it be possible to include experimental bindings in the prerelease branches as well?

Thank you!

WilliamVenner commented 3 years ago

The experimental bindings are kept in WebView2Experimental.idl in the SDK

blckngm commented 3 years ago

Yeah the parser seems to need some modifications to handle the experimental IDL file. I might look into it, but no promises.

But you should be able to use the interfaces without the parser. Just declare them manually, and obtain instances with as_inner and get_interface.

blckngm commented 3 years ago

What specific features do you need? Are they prompted to stable in 1.0.774.44? If so you should be able to use them now with the latest master.

WilliamVenner commented 3 years ago

The file drop handling stuff would be helpful!

blckngm commented 3 years ago

You mean this interface?

/// This interface is continuation of the
/// ICoreWebView2CompositionController interface to manage drag and
/// drop.
[uuid(b134916b-a104-4d2a-9567-c2fd53714350), object, pointer_default(unique)]
interface ICoreWebView2ExperimentalCompositionController3 : IUnknown {

Looks like it's not prompted to stable yet?

I don't have much experience with file drop handling, do you know the difference between this and winit's DroppedFile event, or handling file dropping in HTML/JS?

WilliamVenner commented 3 years ago

That's the one.

winit's DroppedFile handler is pretty basic, it firstly only captures files (and actually crashes due to a debug assertion if you drop a non-file on the window) and secondly emits the DroppedFile event separately for every path, which is a synchronization nightmare.

JavaScript's file drop handling, outside of Electron of course, does not provide absolute file paths, meaning the file paths you receive are pretty much useless if you want to communicate them to the Rust backend and do some work. Either that, or you set up some cursed JavaScript file reader and stream the bytes straight to Rust over a websocket, or worse... JSON. Both of which are a terrible idea if you want to work with very large files.

blckngm commented 3 years ago

Thanks, that's very informative.

Do you know whether experimental interfaces can be used in a non-prerelease SDK?

blckngm commented 3 years ago

I tried to handle WM_DROPFILES, but my window won't get this message if it is occupied by a webview2 webview, instead a new browser window is opened, and the file is opened in it. (https://github.com/MicrosoftEdge/WebView2Feedback/issues/278.) It seems that the drag and drop events are already intercepted by the webview? What would ICoreWebView2ExperimentalCompositionController3 do regarding this?

WilliamVenner commented 3 years ago

One would hope that you can override that behaviour using ICoreWebView2ExperimentalCompositionController3, or in a best case scenario, intercept it, decide what to do with it, and then either override the behaviour or keep the native behaviour.