feat: Implement navigation event and cancellation, closes #456

[atlanticaccent]

What kind of change does this PR introduce?

• Bugfix
• Feature
• Docs
• New Binding issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes, and the changes were approved in issue #___
• No

Checklist

• When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• I have added a convincing reason for adding this feature, if necessary

Other information

• There are likely code style issues with this
• This is only fully implemented for Windows

Notable: the design approach taken is to:

• Make WebContexts generic over user event types so that they can (potentially) store an EventLoopProxy
  • This is non-breaking, as a type alias of WebContextGeneric<()> is provided, named WebContext which effectively hides any generic functionality from consumers that do not need it.
• WebContextBuilders are necessarily also made generic over the user event type, however this should have minimal impact
• The EventLoopProxy is utilised to send a user defined event whenever a navigation occurs.
• An "interface" is effectively defined by WebContextGeneric::with_navigation_event which requires as argument a closure that can construct the user event that is emitted whenever a navigation occurs, thus ensuring that any user defined events also include an event for navigation
• Navigation events cannot be cancelled in "real time", ie: within the event loop. A lambda must instead be provided that is executed within the navigation event handler itself - what difference this makes is unclear, however it does not appear to be a major drawback from what I have seen
• A basic example is included - it demonstrates some notable drawbacks, including: not preventing javascript that effectively rewrites a page (most noticeable when navigating to Twitter and then opening any other user's feeds) and it also does not prevent popups (a future PR or enhancement to this one could prevent this, on Windows at least)

[wusyong]

I think this is a really great feature to be added!
Both linux and mac have similar event callback iirc.
I can help adding them later on.

Could this just be the config of Webview? Webcontext usually describes shared behaviour (like webdriver setup).
And I think it should let users handle event loop proxy themselves. I believe the proxy can be moved into navigation call backs by users.
This should give more freedom for them.

[atlanticaccent]

I could move this code into the webview fairly easily I think, including using the same type aliasing trick to reduce breakage. The reason I picked the WebContext is because it was already being used for things like the webview data directory override, which has a similar execution.

I do think that the EventLoopProxy needs to be explicitly passed in - otherwise the feature is somewhat pointless as a user could write the callback and no event will be emitted. An alternative approach could be to eschew emitting events entirely, and simply take a callback that will be executed when the platform specific event occurs.

[atlanticaccent]

I've done some thinking about your suggestions and reworked the feature's implementation.
There WebContext is no longer generic over users events. As you suggested, users should now just move an event proxy into the callback closure.
WebView and WebViewBuilder can both now add the navigation callback.
There is only one callback, which is where users can define behaviour to execute when the event happens, and also whether to cancel the navigation or not - there didn't seem to much point in having the two closures as separate.
I'm still using WebContext to hold the callback, as holding it as a field on the WebView would still mean adding an additional parameter to all platform webview implementations, when webcontexts are already available to the WebView and are passed into all platform implementations.

[amrbashir]

Looks good so far except the handler shouldn't be tied to WebContext at all. Instead, it should be on Webview same as the ipc handler.

[atlanticaccent]

I've removed all modifications to WebContext and instead stored the navigation handler in WebViewAttributes

[amrbashir]

Webview2 implementation Looking good so far except two small comments below.

[atlanticaccent]

0500e74
Implements WebkitGtk navigation callback handling. Tested under WSL so should presumably work everywhere else

[wusyong]

Here's the one for macos but I suppose it won't be easy to implement if you are not familiar with c/objc ffi.
https://developer.apple.com/documentation/webkit/wknavigationdelegate/1455641-webview?language=objc
I could do this after I'm done with ios/android support.

[atlanticaccent]

I don't really have any experience with objc ffi so if you could lend a hand after the Android port effort that would be great. I'll still try and give it a shot in my own time but I don't expect much

[wusyong]

Just add the macos and it's working!
Now there are two remaining changes I would like to request:
One is switch the condition on returning bool. I think it's more intuitive for true to allow the url and false for not.
The other is make the callback be Box instead of Rc. Is there a place we still need multiple ownership?

I just need the agreement and I'll help pushing the commits. I know some might be busy on work days.

[amrbashir]

One is switch the condition on returning bool. I think it's more intuitive for true to allow the url and false for not.

Seems okay but I could see it the other way around too so we gonna have to document this. and If we want more clarity, we can use an enum

enum Navigation {
  Allow,
  Deny
}

The other is make the callback be Box instead of Rc. Is there a place we still need multiple ownership?

Box is fine.

[wusyong]

I'm very happy with the result. Thank you @atlanticaccent for the help!