1204999 - Disable bfcache when devtools is open

Status: RESOLVED WONTFIX

(DevTools :: Debugger, defect)

Description

[James Long (:jlongster)]

bfcache is an optimization that does not even affect the performance of the current page. It's only used to that "back" is faster. I think this is a very legitimate optimization to disable when devtools is open, because it makes several things very complicated (see bug 1203189, and I'm sure others). Eddy mentioned that we can properly detect worker state changes either.

I have no idea how to even do this, or if others feel strongly about it, but I'm opening this issue for discussion (and maybe to find someone to do it, or at least mentor me)

Comment 1

[James Long (:jlongster)]

Argh my fingers aren't working today. Eddy mentioned that we *can't*...

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

I'm not super against this if it turns out that we have to, but I don't think the bfcache require special casing. It should be equivalent to opening the debugger on a page that is already loaded. More thoughts in bug 1203189 comment 12.

Comment 3

[James Long (:jlongster)]

Eddy, how hard is the problem with workers? It shouldn't be too hard to fix the debugger, I was just curious if we wanted to simplify it or not. So it mostly comes down to how much easier it makes your life with workers.

Comment 4

[Masatoshi Kimura [:emk]]

How can I debug pageshow/load event handlers if devtools disables the bfcache?

Comment 5

[Patrick Brosset <:pbro>]

Note that there's a bit of added complexity in webbrowser.js [1] when dealing with pages that are restored from the bfcache (the mechanism we use to emit events about windows being destroyed/ready/created needs some special handling for pages coming back for that cache iirc).
There's something similar in content-observer.js [2] (which I had no idea existed).

So, based only on this, disabling this functionality would simplify some of our code.

[1] https://dxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/webbrowser.js
[2] https://dxr.mozilla.org/mozilla-central/source/toolkit/devtools/content-observer.js

Comment 6

[Eddy Bruel [:ejpbruel]]

(In reply to James Long (:jlongster) from comment #3)
> Eddy, how hard is the problem with workers? It shouldn't be too hard to fix
> the debugger, I was just curious if we wanted to simplify it or not. So it
> mostly comes down to how much easier it makes your life with workers.

The core of the problem with workers is that workers on the active page have the same window as workers in the bfcache, so the latter keep showing up even though they belong to the previous page.

We have an API to detect when workers are frozen/unfrozen, so we can hide workers from the list when they are moved into the bfcache. The problem with this API is that we also freeze workers when we suspend timers due to the main thread pausing, causing all workers to disappear from the list. If we decide to keep the bfcache, we need some way to distinguish between these two cases.

In my opinion, freezing workers when we suspend timeouts is overkill, and it should be enough to simply suspend them (i.e. queue their events, but do not stop them from running). Bug 1178721 deals with this, but unfortunately the patch I came up with was rejected by khuey. He feels that blocking the main thread should block all workers as well.

The final solution we'll end up adopting for workers will depend on how we decide to deal with the main thread pausing. Either all threads should pause when the main thread pauses, or they shouldn't. This is an ongoing discussion, that I hope will be resolved in the next few weeks.

Needless to say, if we could simply disable the bfcache, we wouldn't have to worry about these issues at all. Hence my preference.

Comment 7

[James Long (:jlongster)]

(In reply to Masatoshi Kimura [:emk] from comment #4)
> How can I debug pageshow/load event handlers if devtools disables the
> bfcache?

You must be talking about Chrome code. You would just debug those handlers with a tab where the page devtools are closed. The browser toolbox will not entirely turn off bfcache for the whole browser.

Comment 8

[James Long (:jlongster)]

How about we vote on this? It sounds like we're on the fence, and it would be nice to have but commonly complicates code. Worker debugging is already highly complex, so it would be nice to not even worry about that. I vote +1 for disabling it.

I'm ni? jimb to have another stakeholder in this that is very involved in the C++ side (not platform as much, but the more people who vote on this the better).

Comment 9

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

My initial reaction is we should keep it on to avoid creating a difference in functionality between DevTools on vs. off.  I do realize that mainly it only affects performance of navigating back and forward in a tab.

However, I am not the one implementing worker support, so even given comment 6, it's not clear to me just how much pain this is.

I would suggest trying to keep bfcache on if we can, but we definitely need good worker support.  If all other options to resolve worker issues from comment 6 fall through / would be very hard to implement, then it seems okay to turn off bfcache.  

Potentially we could keep it on in most cases, but only turn off if you interact with workers?  This way we have less differences from production for most uses of DevTools.

Comment 10

[Masatoshi Kimura [:emk]]

(In reply to James Long (:jlongster) from comment #7)
> (In reply to Masatoshi Kimura [:emk] from comment #4)
> > How can I debug pageshow/load event handlers if devtools disables the
> > bfcache?
> 
> You must be talking about Chrome code.

Why? Page JS can handle those events. If a bug happens only when the page is restored from the bfcache, I can no longer debug it.

Comment 11

[James Long (:jlongster)]

(In reply to Masatoshi Kimura [:emk] from comment #10)
> (In reply to James Long (:jlongster) from comment #7)
> > (In reply to Masatoshi Kimura [:emk] from comment #4)
> > > How can I debug pageshow/load event handlers if devtools disables the
> > > bfcache?
> > 
> > You must be talking about Chrome code.
> 
> Why? Page JS can handle those events. If a bug happens only when the page is
> restored from the bfcache, I can no longer debug it.

Oh, wow, I did not know that was exposed to userland code. If that's the case, there's no way we can avoid supporting it. If you can see a way around this Eddy, feel free to reopen this, but that seems to seal the deal.

Comment 12

[Eddy Bruel [:ejpbruel]]

(In reply to James Long (:jlongster) from comment #11)
> (In reply to Masatoshi Kimura [:emk] from comment #10)
> > (In reply to James Long (:jlongster) from comment #7)
> > > (In reply to Masatoshi Kimura [:emk] from comment #4)
> > > > How can I debug pageshow/load event handlers if devtools disables the
> > > > bfcache?
> > > 
> > > You must be talking about Chrome code.
> > 
> > Why? Page JS can handle those events. If a bug happens only when the page is
> > restored from the bfcache, I can no longer debug it.
> 
> Oh, wow, I did not know that was exposed to userland code. If that's the
> case, there's no way we can avoid supporting it. If you can see a way around
> this Eddy, feel free to reopen this, but that seems to seal the deal.

Yeah, we can work around this. I don't know how yet, but we have options.