RESOLVED FIXED 184750
Add globally-unique HistoryItem identifiers (and have WebKit2 adopt them)
https://bugs.webkit.org/show_bug.cgi?id=184750
Summary Add globally-unique HistoryItem identifiers (and have WebKit2 adopt them)
Brady Eidson
Reported 2018-04-18 13:16:21 PDT
Add globally-unique HistoryItem identifiers (and have WebKit2 adopt them) With process swapping, the WebKit assumption that "back/forward items belong to a process" has been invalidated. So we need to uniquely identify all history items across all processes so there will never be a collision in the global UIProcess namespace. This also lets us get rid of the "per-WebProcess WebBackForwardListItem registry"
Attachments
Patch (67.68 KB, patch)
2018-04-18 22:20 PDT, Brady Eidson
no flags
Patch (69.23 KB, patch)
2018-04-19 09:26 PDT, Brady Eidson
no flags
Patch (69.23 KB, patch)
2018-04-19 09:46 PDT, Brady Eidson
no flags
Patch (69.25 KB, patch)
2018-04-19 10:04 PDT, Brady Eidson
no flags
Brady Eidson
Comment 1 2018-04-18 22:20:54 PDT
Brady Eidson
Comment 2 2018-04-18 22:59:46 PDT
Assume I'll fix the GTK build failure sensibly - Should still be ready for review
Ryosuke Niwa
Comment 3 2018-04-18 23:30:46 PDT
Comment on attachment 338309 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=338309&action=review > Source/WebCore/history/BackForwardItemIdentifier.h:102 > + static void constructDeletedValue(WebCore::BackForwardItemIdentifier& slot) { slot.processIdentifier = makeObjectIdentifier<WebCore::ProcessIdentifierType>(std::numeric_limits<uint64_t>::max()); } Please use ObjectIdentifier<WebCore::ProcessIdentifierType>::hashTableDeletedValue(). Alternatively, define a constructor for HashTableDeletedValueType & add isHashTableDeletedValue to BackForwardItemIdentifier? > Source/WebKit/UIProcess/WebBackForwardList.cpp:422 > + backForwardListItemState.identifier = { Process::identifier(), generateObjectIdentifier<BackForwardItemIdentifier::ItemIdentifierType>() }; Neat! > Source/WebKit/WebProcess/WebPage/WebBackForwardListProxy.cpp:-158 > - updateBackForwardItem(itemID, m_page->pageID(), item.ptr()); Why is it okay to stop calling updateBackForwardItem here? Could you clarify in the change log?
Brady Eidson
Comment 4 2018-04-19 07:38:00 PDT
(In reply to Ryosuke Niwa from comment #3) > Comment on attachment 338309 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=338309&action=review > > > Source/WebCore/history/BackForwardItemIdentifier.h:102 > > + static void constructDeletedValue(WebCore::BackForwardItemIdentifier& slot) { slot.processIdentifier = makeObjectIdentifier<WebCore::ProcessIdentifierType>(std::numeric_limits<uint64_t>::max()); } > > Please use > ObjectIdentifier<WebCore::ProcessIdentifierType>::hashTableDeletedValue(). > Alternatively, define a constructor for HashTableDeletedValueType & add > isHashTableDeletedValue to BackForwardItemIdentifier? > Sure. > > > Source/WebKit/WebProcess/WebPage/WebBackForwardListProxy.cpp:-158 > > - updateBackForwardItem(itemID, m_page->pageID(), item.ptr()); > > Why is it okay to stop calling updateBackForwardItem here? Could you clarify > in the change log? Previously, adding an item was "add or update to the process" followed by "associate that item to the web page" Now it's one step "Add a new item to the page" I'll put this in the changelog
Brady Eidson
Comment 5 2018-04-19 09:26:21 PDT
EWS Watchlist
Comment 6 2018-04-19 09:28:05 PDT
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Brady Eidson
Comment 7 2018-04-19 09:46:03 PDT
Brady Eidson
Comment 8 2018-04-19 10:04:36 PDT
WebKit Commit Bot
Comment 9 2018-04-19 11:45:46 PDT
Comment on attachment 338334 [details] Patch Clearing flags on attachment: 338334 Committed r230812: <https://trac.webkit.org/changeset/230812>
WebKit Commit Bot
Comment 10 2018-04-19 11:45:48 PDT
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 11 2018-04-19 11:46:22 PDT
Sam Weinig
Comment 12 2018-04-19 19:10:56 PDT
Two quick follow up questions: 1) I seem to remember that our long term goal was to try and make it so that back/forward list items were always created in the UIProcess, making among other things, the globally unique id problem trivial. Is that still a goal? 2) What is the reason that WebCore still uses the term HistoryItem? Should we change the name to BackForwardItem (or something like that) at some point (perhaps along with HistoryController)?
Brady Eidson
Comment 13 2018-04-20 13:43:39 PDT
(In reply to Sam Weinig from comment #12) > Two quick follow up questions: > 1) I seem to remember that our long term goal was to try and make it so that > back/forward list items were always created in the UIProcess, making among > other things, the globally unique id problem trivial. Is that still a goal? Sure! > 2) What is the reason that WebCore still uses the term HistoryItem? Should > we change the name to BackForwardItem (or something like that) at some point > (perhaps along with HistoryController)? There's no reason to be HistoryItem instead of BackForwardListItem. I considered it here, but didn't do it because it would've taken half a day of fighting will all the platforms and all the build systems.
Note You need to log in before you can comment on or make changes to this bug.