"Disable Cache" does not work with Fission when the browser toolbox is open
Categories
(DevTools :: Netmonitor, defect, P3)
Tracking
(Fission Milestone:Future)
Fission Milestone | Future |
People
(Reporter: bomsy, Unassigned)
References
(Blocks 2 open bugs)
Details
(Whiteboard: dt-fission-future)
STR
- Go to https://farooqar.github.io/sse-echo/
- Open the network monitor
- Open the browser toolbox
- Make sure all the Fission prefs are on
- Check the "Disable cache" checkbox
- 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.
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 1•4 years ago
|
||
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?
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 2•4 years ago
|
||
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.
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Comment 3•4 years ago
•
|
||
dt-fission-future
bugs don't need to block Fission MVP, so I'm moving them to Fission Future.
Comment 4•4 years ago
|
||
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.
Updated•3 years ago
|
Description
•