1720443 - The Debugger does not hit breakpoint when navigating BACK to page with a breakpoint set

Status: RESOLVED FIXED

(DevTools :: Debugger, defect)

Description

[Hubert Boma Manilla (:bomsy)]

Prefs:

• fission.autostart => true
• devtools.target-switching.server.enabled => true
• fission.bfcacheInParent => true

1. Load http://janodvarko.cz/tests/fission/case1/index.html
2. Create BP in janodvarko.cz/index.js file, line 3
3. Reload page to hit breakpoint => OK
4. Load different page, e.g. http://janodvarko.cz/firebug/tests/601/Issue601.htm in same tab
5. Go back to http://janodvarko.cz/tests/fission/case1/index.html page using the BACK BUTTON

AR
The breakpoint is not hit

ER
The breakpoint should get hit

Note
With fission.bfcacheInParent => false, the breakpoint is hit (Works properly)

Comment 1

[Hubert Boma Manilla (:bomsy)]

Also note:
i also sometimes do not get the sources at all when going BACK

Comment 2

[Hubert Boma Manilla (:bomsy)]

Attachment: Bug 1720443 - [devtools] Fix breakpoint not hit on go back (WIP)

Comment 3

[Chris Peterson [:cpeterson]]

This bug is a soft blocker for Fission MVP. We'd like to fix it before our Release channel rollout, but we won't delay the rollout waiting for it.

Comment 4

[Alexandre Poirot [:ochameau]]

First important point to note is that this STR is invalid if BFCache actually works.

The breakpoint we set on index.js line 3 will not fire when navigating back to the page, because the whole point of BFCache is to avoid loading the page again. So index.js won't be loaded again, instead we will only restore the page from the cache and won't re-evaluate the JS files.
If we want to trigger a breakpoint on history/bfcache navigations, we should set a breakpoint on a pageshow/pagehide listener.

window.addEventListener("pageshow", function () {
  console.log("restored from the bfcache"); // Here for navigating back to this page
});

window.addEventListener("pagehide", function () {
  console.log("saved into the bfcache"); // Here for navigating away from this page
});

Given that the STR only reproduces with bfcacheInparent = true, it might mean that the new bfcacheInParent enables storing the paused page in the cache, while the previous bfcache implement wasn't.

Then, while the STR is invalid about the breakpoint not being hit, there is also an issue with sources. Sources aren't displayed after step 5.
But it is even worse than this, the page is blank. So that the breakage goes beyond DevTools.

After some investigations, it looks like the way we resume the page when navigating away from the pause page, on step 4 is a source of troubles.
If I comment out this line:
https://searchfox.org/mozilla-central/rev/a9db89754fb507254cb8422e5a00af7c10d98264/devtools/server/actors/thread.js#1778

      this.doResume();

It fixes all the issues here. The breakpoint is hit as before, meaning bfcache is not working and we reload the page on step 5.

I recently changed this code in bug 1717005. It would be enlightning to know if unsafeSynchronize was actually any helpful here about that...!!
It would be also useful to know if this also fixes bug 1722305?

One idea is that by resuming on navigating away, we might allow bfcacheInParent to save the page in the bfcache, but in a broken way.
Whereas, if we don't resume at all on navigating away, we prevent bfcache from working and everything works (as before fission).
Note that I think it is fine having bfcache being disable on paused pages.

Comment 5

[Hubert Boma Manilla (:bomsy)]

Tested this again, and it has been fixed!