WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
147525
WebKit2 Removed API to change WebKit2.BackwardForwardList
https://bugs.webkit.org/show_bug.cgi?id=147525
Summary
WebKit2 Removed API to change WebKit2.BackwardForwardList
Sam P.
Reported
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
)
Attachments
Add attachment
proposed patch, testcase, etc.
Brady Eidson
Comment 1
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.
Sam P.
Comment 2
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.
Brady Eidson
Comment 3
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);
Sam P.
Comment 4
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
>.
Brady Eidson
Comment 5
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"
Anders Carlsson
Comment 6
2015-08-03 10:23:29 PDT
We're not going to add this back.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug