Feature to persist sessions to file

[jgraef]

This PR adds a feature (behind the feature-flag persist) that allows a WebDriver session to be persisted to disk.

WebDriver::persist will consume self and return a PersitedSession that contains the session ID and capabilities.

PersistedSession::connect allows to turn a persisted session back into a WebDriver.

PersistedSession is also Serialize and Deserialize, so it can easily be written to a file.

[stevepryde]

The idea is interesting but I'm curious what the use-case is. Selenium browser sessions are typically short, at least in a testing context. It may be helpful to provide some documentation, particularly at the module level, so that future readers and contributors will know what the primary intention for this feature is. Thanks :)

[stevepryde]

Does this work? My thinking is that it should be impl GenericWebDriver instead.

Also, would you be happy to add a test or doctest for the persist() -> connect() round trip?

[jgraef]

Hmm, it probably should be GenericWebDriver, but this definitely compiles and even runs!

I can add a test, when I have some time. It might take a while, but I guess we can keep the PR open until then.

[stevepryde]

I don't think a test would be difficult at all. Have a look at the doctests for WebDriverCommands etc. All this would require is to create a session, persist it to a file, destroy the original, then reload the session from the file and issue some command to it. I think that would be sufficient as a minimal way to sanity check this feature.

Happy to keep the PR open :)

[stevepryde]

Note that you can use docker-compose up -d to run the demo web app that all doctests use. It will be accessible at http://localhost:8000 when it runs. By looking at the other tests you will see how this is being used. It's a fairly simple yet robust way to test everything against an actual selenium instance and browser.

You can then use cargo test --features=persist to run all tests. You can also add part of the method name at the end to only run your particular test.

Once there are doctests for this I'd also like this to be added to the automated build (Github Actions) so that this feature is regularly tested with every build, but I can add that later :)

[jgraef]

My use-case: I use this to control a Chromium browser to browse through Instagram, but I imagine any website with a lot of dynamic content and good bot-detection is probably better scraped using a real browser.

During debugging I just didn't want to have it always open a new browser and logging in. With a persisted session I can run my client to first open a browser and login. And then with subsequent commands I can load different pages and extract information.

[stevepryde]

Thanks for outlining the use-case. There have been requests to support connecting to an existing session in the past so I see this as another variant of that idea.

[stevepryde]

Due to upcoming changes to thirtyfour (refactor to use fantoccini as a base), this change is no longer applicable.