As-is, late-arriving PSG events can be interpreted and handled against a WebContents (et al) that has been re-navigated. This can lead to premature state transitions in the TabLoadTracker for the re-navigated WC, and may cause performance and characteristics data to be persisted against the wrong origin.
The fix is to
- give navigations an identity, and to
- adorn all PSG notifications with the associated navigation identity, and to
- match arriving events against the current navigation identity, and to
- drop events that don't match the current navigation.
For the persistence case, it might be of short term benefit to funnel the origin through as well, as that will allow persisting data even post re-navigation. The long-term plan is probably to push the persistence into the RC sequence by endowing the graph with a suitable writer on navigation commit.
Comment 1 by sebmarchand@chromium.org
, Jun 20 2018