DescriptionGuestViewManager mapped <owner WebContents, element instance ID> => guest instance ID on attachment. This routed IPCs from a given BrowserPlugin to the appropriate guest.
Element instance IDs are unique per process. This mapping is fine in Chrome Apps where the embedder doesn't navigate but not for when the embedder is capable of cross-process navigation. In that case, element instance IDs of two BrowserPlugins in two different embedder processes of the same WebContents have the same key, and would thus route to the same guest.
This is an issue because the lifetime of the exiting document overlaps with the lifetime of the entering document. Thus, racy behavior can occur. In particular, when navigating from one PDF to another, IPCs for tear down destined for the exiting BrowserPlugin can occasionally get routed to the entering BrowserPlugin. In bug 436339's case, the first step of tear down is to hide the guest content. That IPC ends up going to the entering guest, and so the new PDF is not displayed on screen.
This CL fixes the issue by using <embedder process id, element instance ID> as the key to map to a guest instead of the embedder WebContents as the first component.
BUG=436339
Committed: https://crrev.com/833ee7ced817effed9202b9cfddf85b067cf0edf
Cr-Commit-Position: refs/heads/master@{#316328}
Patch Set 1 #Patch Set 2 : More cleanup #Patch Set 3 : Cleanup #Patch Set 4 : More cleanup #
Total comments: 2
Patch Set 5 : Addressed nit #
Total comments: 4
Patch Set 6 : Addressed comments #Patch Set 7 : Fixed PDF nav #Patch Set 8 : Remove render_view_routing_id() from GuestViewContainer #
Total comments: 8
Patch Set 9 : Addressed comments #
Total comments: 4
Patch Set 10 : Updated comments CQ'ing #Messages
Total messages: 21 (5 generated)
|