oxide team mailing list archive

[Chris Coulson <chris.coulson@xxxxxxxxxxxxx>]

On 04/08/14 16:50, Olivier Tilloy wrote:
> Hi,
>
> I’m working on adding support for session save/restore to the
> webbrowser app in Ubuntu Touch.
>
> The first iteration will be somewhat naive and will only restore the
> current URL for each open tab (no navigation history, no current
> scroll offset, no nothing). This approach has the advantage of being
> implementable without changes in oxide, which fits well our aggressive
> time constraints for now.
>
> In the future we’ll want to implement a much more clever session
> restore mechanism, where navigation history and current scroll offset
> are being restored as well (any other interesting parameters we should
> save and restore?).
>
> This will require some work in oxide to allow instantiating a WebView
> with saved data, I suppose similar to what is done today when passing
> a OxideQNewViewRequest at construction time. We’ll also need an API to
> save the navigation history (and scroll offset, but that’s easy) to a
> format that can be persisted (not sure if the persistence itself
> should be built in oxide, or should be left up to the embedder). Does
> that make sense?
>
> I haven’t thought much of what the API would look like yet,
> suggestions and comments are welcome!
>
> Cheers,
>
>  Olivier
>
>
Hi,

This sounds fine. Some general comments:

- You're probably right about passing a construct parameter to create a
WebView with saved state - content::NavigationController::Restore() can
only be called before there are any navigation entries, and WebContents
must be created with additional data too.
- content::PageState provides a per-NavigationEntry opaque blob of data
that blink can use to restore various bits of page state (such as scroll
offset and form data).
- The application should probably be responsible for managing the actual
storage of the saved state (ie, using its own storage backend).
- However, we shouldn't expect the application to do anything with the
data beyond storing it to disk, and passing it to a new WebView. The
data should be opaque.

With that in mind, the API would probably just be a couple of properties:

QString WebView.initialState (writable during construction)
QString WebView.currentState (read only)

Regards
- Chris

Attachment: signature.asc
Description: OpenPGP digital signature