Bugzilla

This issue highlight some race condition in TargetCommand where, in case of bfcache navigation, we sometime receive the iframe target *before* the top level one.
Because of this, we receive the iframe target first, add it to the cache, notify it to the panel.
But then, when we receive the top document iframe, we destroy the iframe target because of this code:
https://searchfox.org/mozilla-central/rev/9dceacf3d761eb91237108ec438d64099a56f442/devtools/shared/commands/target/target-command.js#168

We probably have to workaround the fact that the platform code doesn't fire pageshow event in DevToolsFrameChild in the best order for us.
https://searchfox.org/mozilla-central/rev/9dceacf3d761eb91237108ec438d64099a56f442/devtools/server/connectors/js-window-actor/DevToolsFrameChild.jsm#616

Sounds like something we should fix sooner than later, but given that it is specific to bfcache *and* iframes, it doesn't justify backing out SSTS, nor delaying M3.
It is yet another edgecase related to bfcache navigations.

This issue highlight some race condition in TargetCommand where, in case of bfcache navigation, we sometime receive the iframe target *before* the top level one.
Because of this, we receive the iframe target first, add it to the cache, notify it to the panel.
But then, when we receive the top document, we destroy the iframe target because of this code:
https://searchfox.org/mozilla-central/rev/9dceacf3d761eb91237108ec438d64099a56f442/devtools/shared/commands/target/target-command.js#168

We probably have to workaround the fact that the platform code doesn't fire pageshow event in DevToolsFrameChild in the best order for us.
https://searchfox.org/mozilla-central/rev/9dceacf3d761eb91237108ec438d64099a56f442/devtools/server/connectors/js-window-actor/DevToolsFrameChild.jsm#616

Sounds like something we should fix sooner than later, but given that it is specific to bfcache *and* iframes, it doesn't justify backing out SSTS, nor delaying M3.
It is yet another edgecase related to bfcache navigations.