Open Bug 1692759 Opened 4 years ago Updated 3 years ago

"Disable Cache" does not work with Fission when the browser toolbox is open

Categories

(DevTools :: Netmonitor, defect, P3)

defect

Tracking

(Fission Milestone:Future)

Fission Milestone Future

People

(Reporter: bomsy, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: dt-fission-future)

STR

  1. Go to https://farooqar.github.io/sse-echo/
  2. Open the network monitor
  3. Open the browser toolbox
  4. Make sure all the Fission prefs are on
  5. Check the "Disable cache" checkbox
  6. Refresh the page multiple times

AR

The /sse-echo/ request shows a 200 status the first time and 304 on all
subsequent refreshes.

ER

The /sse-echo/ request should show always show a 200 status on all refreshes.

Whiteboard: dt-fission-m3-triage

Did a bit of investigation, it looks like we enable the cache in _restoreDocumentSettings https://searchfox.org/mozilla-central/rev/8cb90829ccf18f95cd75d8419c84729c754a8e83/devtools/server/actors/targets/browsing-context.js#1286 which is executed on detaching from the browsing context. In fission it looks like this happens on each reload.
I'm not sure we need to reset the cache here.

Alex,
Is there a reason why for doing that?

Flags: needinfo?(poirot.alex)
Summary: "Disable Cache" does not work with Fission → "Disable Cache" does not work with Fission when the browser toolbox is open

So after discussing with Alex (offline), this only occurs when the browser toolbox is open along with the web toolbox. This means that there are two targets actors interacting with the same BrowsingContext and overriding the same docShell.defaultLoadFlags value. There is also no guarantee which instance will run first, introducing race concerns.

Whiteboard: dt-fission-m3-triage → dt-fission-future
Severity: -- → S3
Priority: -- → P3

dt-fission-future bugs don't need to block Fission MVP, so I'm moving them to Fission Future.

Fission Milestone: --- → Future

We should probably move this flag to the BrowsingContext and set it from the parent, similarly to what we have been doing in bug 1690100.
This wouldn't solve the Browser toolbox versus Tab toolbox situation immediately.
As I think the TargetConfiguration doesn't address this edgecase yet.
But it is meant to address that eventually.

Migrating the Cache disabled from BrowsingContextTargetActor to TargetConfiguration would actually help on some other edgecase.
Like when we navigate to a new process/target, this would help ensure the cache is kept disabled.
It would also help disabling cache in remote iframes.

Flags: needinfo?(poirot.alex)
You need to log in before you can comment on or make changes to this bug.