We no longer need to throw away suspended pages in a process before using it for a navigation, now that Bug 201225 has been fixed. WebPage objects (suspended or live) in the process now have distinct identifiers and can coexist.
Created attachment 377740 [details] Patch
Comment on attachment 377740 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=377740&action=review > Source/WebKit/Shared/API/Cocoa/RemoteObjectRegistry.h:72 > - WebPageProxyIdentifier m_messageDestinationID; > + uint64_t m_messageDestinationID; I don't quite understand how this works without fixed type?
Comment on attachment 377740 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=377740&action=review >> Source/WebKit/Shared/API/Cocoa/RemoteObjectRegistry.h:72 >> + uint64_t m_messageDestinationID; > > I don't quite understand how this works without fixed type? Not sure I understand the question, it is only used for IPC so it does not need to be a strong type. The reason I am no longer using a Strong type is that RemoteObjectRegistry.h is used from in the UIProcess and in the WebContent process. When running in the WebContent process, the destinationID is a WebPageProxyIdentifier, when running in the UIProcess, the destinationID is a WebCore::PageIdentifier. Now that we can have several WebPages in the same WebContent process mapping to the same WebPageProxy in the UIProcess, it is important that RemoteObjectRegistry objects in the WebContent process listen to IPC on the WebCore::PageIdentifier id and not a WebPageProxyIdentifier id. Using a WebPageProxyIdentifier, we'd get a conflict, having several objects listen to IPC on the same id in the same process.
Created attachment 377752 [details] Patch
Comment on attachment 377752 [details] Patch Clearing flags on attachment: 377752 Committed r249350: <https://trac.webkit.org/changeset/249350>
All reviewed patches have been landed. Closing bug.
<rdar://problem/54900270>