1552686 - Firefox fires devtools.network.onNavigated at the wrong time

Status: NEW

(WebExtensions :: Developer Tools, defect, P3)

Description

[Ian Moody [:Kwan] (UTC+0)]

Currently Firefox fires onNavigated at a very different time to Chromium, seemingly randomly among the onRequestFinished events for the page's subresources, whereas Chromium always fires it before any onRequestFinished event, including the one for the navigated-to page.
As well as being a compat issue, Firefox's behaviour is less useful, since it prevents associating onRequestFinished events for subresources with the parent document, since they will fire at a mixture of points before and after onNavigated, whereas in Chromium they all fire after.

This can be demonstrated with attachment 8990908 [details] from bug 1472653.

Bug 1341089 deliberately moved from the "will-navigate" to "navigate" event so that inspectedWindow.eval would eval in the new window, rather than the old one, but Chromium manages to both fire onNavigated first and still eval in the correct, new, window.

Comment 1

[Kris Maglione [:kmag]]

Firefox's page load cycle works differently from Chrome's, so you'll need to expect some differences. I don't know the details of Chrome's load cycle, but in Firefox, you can't expect network requests to have much relationship to what's currently shown in the browser. We begin loading subresources when the parser encounters them, which happens on a background thread, before we've even created any nodes. But the time we actually begin displaying a document, a large portion of its resources may already have been loaded.

Arguably, we should probably fire this event on DOMWindowCreated, though. It looks like right now it's fired on DOMContentLoaded.

Comment 2

[Ian Moody [:Kwan] (UTC+0)]

Yeah differences to Chrome aren't that surprising (and frankly I don't care that much about Chrome compat), but that fact it comes in not just after the onRequestFinished for the page but randomly amongst the onRequestFinished for the subresources is surprising, and prevents some use cases.

Comment 3

[marvin]

Can confirm that this issue is still present in Firefox 87.0 .

My extension is activated by a content script. This happens via acknowledging each other's message after which the content scripts starts do its work. When a page navigates the devtools panel needs to clear all current ui state and start fresh. But when the page loads, the content script establishes a connection again and sends data, and seemingly at random after that the chrome.devtools.network.onNavigated event fires. So the panel thinks "ohh a navigation happened, let me clear the ui".

So chrome.devtools.network.onNavigated is not a reliable source to trigger logic based on page navigated. It just fires whenever and waaay too late to be useful. Very much agree with Ian above.