Consider the following situation (one among many possible). - FrameA has an oopif child FrameB; - FrameA navigates to same-process origin (e.g. about:blank); - at the same time, FrameC is attached to the FrameB in the FrameB's process. In this case, we get `frameNavigated` event for FrameA, immediately followed by `frameAttached` event for FrameC. Since we detach all FrameA's child frames on navigation, including the oopif FrameB, there is no parent frame for FrameC to attach to. In general, multiple processes coming from oopif may send their events in wildly different order, and their view about the frame tree may not always correspond to the "up to date" frame tree as seen from the main frame's process. We try to keep our frame tree aligned with what main process thinks, and ignore events that reference frames absent in this tree. Drive-by: handle filechooser exceptions because of async processing. |
||
|---|---|---|
| .. | ||
| chromium.ts | ||
| crAccessibility.ts | ||
| crBrowser.ts | ||
| crConnection.ts | ||
| crCoverage.ts | ||
| crDevTools.ts | ||
| crExecutionContext.ts | ||
| crInput.ts | ||
| crNetworkManager.ts | ||
| crPage.ts | ||
| crPdf.ts | ||
| crProtocolHelper.ts | ||
| protocol.ts | ||
| videoRecorder.ts | ||