These tests fail with BFCache+Fission
toolkit/components/passwordmgr/test/browser/browser_autocomplete_footer.js
toolkit/components/passwordmgr/test/browser/browser_context_menu.js
toolkit/components/passwordmgr/test/browser/browser_doorhanger_generated_password.js
toolkit/components/passwordmgr/test/browser/browser_entry_point_telemetry.js
toolkit/components/passwordmgr/test/browser/browser_private_window.js

failure log: https://treeherder.mozilla.org/logviewer?job_id=332690188&repo=try&lineNumber=42436

Prefs to use: fission.autostart and fission.bfcacheInParent

Neil, can you please debug these failures?

Three of these tests fail due to a telemetry issue: browser_autocomplete_footer.js, browser_context_menu.js and browser_entry_point_telemetry.js.

When the logins page is loaded, it will load, for example, 'about:logins?filter=www.mozilla.org&entryPoint=pageinfo' and record telemetry for the opening of the logins manager. The page will then strip off the entryPoint parameter and assign that url as the current page (using window.location.replace). Telemetry attempts to get recorded again for ''about:logins?filter=www.mozilla.org'.

However, the code at https://searchfox.org/mozilla-central/rev/62135a96327f42fd1ccf8a04feb62be04b102195/browser/components/aboutlogins/AboutLoginsChild.jsm#176-192 detects this case and filters out this second telemetry because the outerWindowId of both are the same.

With bfcacheinparent enabled, the outerWindowId is different and telemetry is recorded twice, causing the tests to fail.

Changing the login manager to ignore setting telemetry when an entryPoint is not present causes all three tests to pass, but I assume that won't handle the case where one opens the login manager directly.

Is it a bug that the outerWindowId be the different for both about:login loads? Or can the login manager use some other identifier to detect the 'redirect'?

If there is a browsingcontext swap (which can happen because of bfcache or coep/coop for example), the outer window in the child process does change, since there will be a new browsing context. This all is very much expected.

The same browser ID is used in the browsing contexts https://searchfox.org/mozilla-central/rev/62135a96327f42fd1ccf8a04feb62be04b102195/dom/chrome-webidl/BrowsingContext.webidl#185
Could that work here?

(In reply to Olli Pettay [:smaug] from comment #3)

The same browser ID is used in the browsing contexts https://searchfox.org/mozilla-central/rev/62135a96327f42fd1ccf8a04feb62be04b102195/dom/chrome-webidl/BrowsingContext.webidl#185
Could that work here?

I think it probably would work in this case. Looking at the code in more detail it seems to just block about:login loads that occur within 5 seconds of another one. Since reloading about:logins isn't like that is unlikely I don't think it would affect the telemetry being measured.

Depends on D111406

https://hg.mozilla.org/mozilla-central/rev/4300381e072c
https://hg.mozilla.org/mozilla-central/rev/c406f48b922b