147525 2015-08-01 00:54:20 -0700 WebKit2 Removed API to change WebKit2.BackwardForwardList 2015-08-03 10:23:29 -0700 1 1 1 Unclassified WebKit WebKitGTK 528+ (Nightly build) PC Linux RESOLVED WONTFIX P2 Normal --- 1 sam webkit-unassigned andersca beidson sam sam oldest_to_newest 1114002 0 sam 2015-08-01 00:54:20 -0700 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) 1114067 1 beidson 2015-08-01 15:12:08 -0700 (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. 1114069 2 sam 2015-08-01 15:16:24 -0700 (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. 1114071 3 beidson 2015-08-01 15:20:54 -0700 (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); 1114072 4 sam 2015-08-01 15:27:07 -0700 (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>. 1114073 5 beidson 2015-08-01 15:38:47 -0700 (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" 1114216 6 andersca 2015-08-03 10:23:29 -0700 We're not going to add this back.