Bug 147525 - WebKit2 Removed API to change WebKit2.BackwardForwardList
Summary: WebKit2 Removed API to change WebKit2.BackwardForwardList
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-01 00:54 PDT by Sam P.
Modified: 2015-08-03 10:23 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sam P. 2015-08-01 00:54:20 PDT
In the WebKit1 API, it was possible to change a WebView's back/forward list.

For example, it was possible to reconstruct the history of a WebView (python):

    back_forward_list = webview.get_back_forward_list()
    back_forward_list.clear()  # removed in WebKit2
    
    for uri, title in histroy:
        history_item = WebKit.WebHistoryItem.new_with_data(uri, title)  # removed in WebKit2
        back_forward_list.add_item(history_item)  # removed in WebKit2

However there doesn't seem to be a workaround/replacement for these removals.

(Continuing from the discussion on https://bugs.webkit.org/show_bug.cgi?id=69343#c23)
Comment 1 Brady Eidson 2015-08-01 15:12:08 PDT
(In reply to comment #0)
> In the WebKit1 API, it was possible to change a WebView's back/forward list.
> 
> For example, it was possible to reconstruct the history of a WebView
> (python):
> 
>     back_forward_list = webview.get_back_forward_list()
>     back_forward_list.clear()  # removed in WebKit2
>     
>     for uri, title in histroy:
>         history_item = WebKit.WebHistoryItem.new_with_data(uri, title)  #
> removed in WebKit2
>         back_forward_list.add_item(history_item)  # removed in WebKit2
> 
> However there doesn't seem to be a workaround/replacement for these removals.
> 
> (Continuing from the discussion on
> https://bugs.webkit.org/show_bug.cgi?id=69343#c23)

WK2 has been developed under the philosophy that allowing direct API client manipulation of a live back/forward list was a mistake.

It caused way more crashing, correctness, and security bugs that one would think, and so far we've found alternate ways for clients to accomplish what they figured they needed list manipulation for.

Can you concisely state what you did in WK1 that you can't do in WK2? Perhaps an alternative already exists, or can be implemented differently than making the list client mutable.
Comment 2 Sam P. 2015-08-01 15:16:24 PDT
(In reply to comment #1)
> Can you concisely state what you did in WK1 that you can't do in WK2?
> Perhaps an alternative already exists, or can be implemented differently
> than making the list client mutable.

The users instance in a browser was saved in their journal.  The saved data was the back/forward list and position for each tab.  When loading the data, a new webview would be created and the back/forward list would be recreated from the data (as per the code in comment #0).  This was to facilitate the desired design of the user being able to restore the browser state.
Comment 3 Brady Eidson 2015-08-01 15:20:54 PDT
(In reply to comment #2)
> (In reply to comment #1)
> > Can you concisely state what you did in WK1 that you can't do in WK2?
> > Perhaps an alternative already exists, or can be implemented differently
> > than making the list client mutable.
> 
> The users instance in a browser was saved in their journal.  The saved data
> was the back/forward list and position for each tab.  When loading the data,
> a new webview would be created and the back/forward list would be recreated
> from the data (as per the code in comment #0).  This was to facilitate the
> desired design of the user being able to restore the browser state.

In what way does saving/restoring session state not solve this?

See WKPage.h:
WK_EXPORT WKTypeRef WKPageCopySessionState(WKPageRef page, void* context, WKPageSessionStateFilterCallback urlAllowedCallback);

WK_EXPORT void WKPageRestoreFromSessionState(WKPageRef page, WKTypeRef sessionState);
Comment 4 Sam P. 2015-08-01 15:27:07 PDT
(In reply to comment #3)
> In what way does saving/restoring session state not solve this?
> 
> See WKPage.h:
> WK_EXPORT WKTypeRef WKPageCopySessionState(WKPageRef page, void* context,
> WKPageSessionStateFilterCallback urlAllowedCallback);
> 
> WK_EXPORT void WKPageRestoreFromSessionState(WKPageRef page, WKTypeRef
> sessionState);

That function doesn't seem to be in the gtk bindings <http://webkitgtk.org/reference/webkit2gtk/stable/index-all.html>.
Comment 5 Brady Eidson 2015-08-01 15:38:47 PDT
(In reply to comment #4)
> (In reply to comment #3)
> > In what way does saving/restoring session state not solve this?
> > 
> > See WKPage.h:
> > WK_EXPORT WKTypeRef WKPageCopySessionState(WKPageRef page, void* context,
> > WKPageSessionStateFilterCallback urlAllowedCallback);
> > 
> > WK_EXPORT void WKPageRestoreFromSessionState(WKPageRef page, WKTypeRef
> > sessionState);
> 
> That function doesn't seem to be in the gtk bindings
> <http://webkitgtk.org/reference/webkit2gtk/stable/index-all.html>.

I'd suggest trying to get it into the GTK bindings, since it's literally just a bindings issue.

Session saving/restoring is specifically for this use case, and has higher fidelity than just "a list of URLs"
Comment 6 Anders Carlsson 2015-08-03 10:23:29 PDT
We're not going to add this back.