QtWebKit1 had this api in QWebHistory. WK2 implements this via WKPageGoToBackForwardListItem(WKPageRef page, WKBackForwardListItemRef item); It needs to be added to Qt APIs.
Created attachment 88120 [details] Proposed patch to add load from history Proposed patch adds the api to QWKPage - A little different from how it was in WK1, since in '2, history knows nothing about the current page. Also added an access method for WKBackForwardListItemRef in QWKHistoryItem... similar thing is done with QWKPage and pageRef.
Comment on attachment 88120 [details] Proposed patch to add load from history Missing tests and doc. I know most methods do in WK2, but that is no excuse for new addition :)
Very well, I've created 57850 to write tests for (existing) qwkhistory (which doesn't have any). I think that this needs to be done before I can even address test cases for this bug.
(In reply to comment #2) > (From update of attachment 88120 [details]) > Missing tests and doc. > I know most methods do in WK2, but that is no excuse for new addition :) I don't think it's necessary to add doc for the Qt/WK2 APIs at this stage. We will need a ChangeLog entry though. :) On another note, this API is rather dirty. - The name implies that a load will happen, whereas it may as well be a cached page restoration (depending on availability.) The old QWebHistory::goToItem() made more sense in this regard. - What if the QWKHistoryItem passed to QWKPage::loadFromHistory() comes from another QWKPage's history()? Since the QWKHistory points to a WebBackForwardList, which internally has a WebPageProxy*, I think it would make more sense that the QWKHistory be aware of the QWKPage that owns it. This way we could put a WK1-style goToItem() into QWKHistory instead.
> Since the QWKHistory points to a WebBackForwardList, which internally has a WebPageProxy*, I think it would make more sense that the QWKHistory be aware of the QWKPage that owns it. This way we could put a WK1-style goToItem() into QWKHistory instead. Now that the other bug to add test content is committed, I'll start to re-work this as you are suggesting. This means that QWKHistory will have to maintain a pointer to it's owner page? I'll write it up and see what you all think. I always felt like the way I did it here was a little funny, but didn't want to change things around too much. Let's see...
Created attachment 95784 [details] Patch
(In reply to comment #6) > Created an attachment (id=95784) [details] > Patch So I've implemented something like what you've suggested. For this time I chose the easiest route, and just passed a copy of the (public) QWKPage into history so it has a copy of it (as opposed to granting/enabling access to private or something like this). I toyed with the idea of changing the QWKHistory instantiation to pass in QWKPage instead of a pointer to the WKBackForward list, and fetching the list inside of QWKHistory's constructor. However, amongst all the toAPI and toImpl and stuff in the WK2API I couldn't figure out how to fetch it. If you would rather I do something like this instead, please suggest how to fetch it. I named the public API "goToItemAt" after "itemAt" and use the integer-style api. Currently it silently fails if int is out of range. Don't know how you feel about this either, but it's easy to change.
Created attachment 98347 [details] Patch
Comment on attachment 98347 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=98347&action=review Looks mostly great, just some minor itches: > Source/WebKit2/ChangeLog:8 > + Created "random access" ForwardBackHistory public API method, Typo, BackForwardHistory. > Source/WebKit2/ChangeLog:17 > + Updated createHistroy method and QWKHistoryPrivate constructor to take a pointer Typo, createHistory. > Source/WebKit2/ChangeLog:18 > + to the owning QWKPage in addtion to the WebBackForwardList. This will be saved so that the Typo, addition. > Source/WebKit2/UIProcess/API/qt/qwkhistory.h:51 > + WKBackForwardListItemRef itemRef() const; We shouldn't use WK2 types in our APIs, QWKHistory and QWKHistoryItem should be friends and grab at each others private members directly instead.
Created attachment 98377 [details] Patch - respun changed after klings comments.
Respun changes after kling's comments. (In reply to comment #10) > Created an attachment (id=98377) [details] > Patch
Comment on attachment 98377 [details] Patch - respun changed after klings comments. LGTM
Comment on attachment 98377 [details] Patch - respun changed after klings comments. Clearing flags on attachment: 98377 Committed r89605: <http://trac.webkit.org/changeset/89605>
All reviewed patches have been landed. Closing bug.