Summary: | WebKit2 Removed API to change WebKit2.BackwardForwardList | ||
---|---|---|---|
Product: | WebKit | Reporter: | Sam P. <sam> |
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | andersca, beidson, sam, sam |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | PC | ||
OS: | Linux |
Description
Sam P.
2015-08-01 00:54:20 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. (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 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); (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>. (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" We're not going to add this back. |