webdriver support

[chippers]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Documentation
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes. Issue #___
• No

The PR fulfills these requirements:

• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:
I marked this as a draft cause the interfaces are not final. If a release is not planned soon, then this can be merged and the Application interface can be worked on before the next release. LMK if the non-final interface is okay to merge for now and I'll mark it for review.

Overall this was less lines of code than I thought, but putting it together correctly in the right order was important. I guess since we are heavily leveraging existing webdriver servers (WebKitWebDriver and msedgedriver) it was mostly about enabling proper support for them.

Some notes on the changes:

• webkit2gtk starts webdriver support on v2_18 so I bumped it up to that.
• unix::ApplicationExt allows setting the automation flag for Application because there is only allowed to be 1 automation context at a time. The other platforms have similar limitations I imagine (just from how webdriver works typically), but webkit2gtk semi-enforces this through the api.
  • Note: By default the context is an automation context. This just means it allows automation and not that it requires it.
• wry::Application is back for the above reason. It should be thought of/acts like a "browser" where there might be multiple windows and/or tabs but it refers to the same context. Like how incognito mode is a single context that shares multiple windows/tabs. It doesn't really do anything other than represent some context specific data.

I'm thinking that wry::Application can be made into a builder, and start adding items that are getting passed to InnerWebView::new() to it that make sense. So far, I've only moved over data_directory.

Also, because we now have wry specific stuff in application (Application and mod unix), it gets mixed in with the tao re-exports. Maybe we should move the tao re-export to the crate root and maybe also add root re-exports for items expected to be used by most wry applications (EventLoop, WindowBuilder, Application, WebviewBuilder, ect...)

only linux + windows for now

[chippers]

@wusyong tagging you in a comment since I don't want to mark this as Review until we know how we want to expose Application (I'm thinking a builder).

[wusyong]

I prefer to move all the setup of Application type into WebViewBuilder.
I looked up the ApplicationInner for Linux and Windows. And it should be possible to pass those fields into WebViewInner with WebViewBuilder I believe.

[chippers]

I prefer to move all the setup of Application type into WebViewBuilder.
I looked up the ApplicationInner for Linux and Windows. And it should be possible to pass those fields into WebViewInner with WebViewBuilder I believe.

I'll look into this approach

[chippers]

right now the unix::WebContextImpl struct is behind a private crate module, since it's only used internally for now. Realistically this information isn't problematic to expose publicly, should the web_context module be pub (and therefore the unix module and unix::WebContextExt also)?