Throttle ResourceWatcher events on the client side
Categories
(DevTools :: Framework, enhancement)
Tracking
(Fission Milestone:M6c, firefox83 fixed)
Tracking | Status | |
---|---|---|
firefox83 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
(Blocks 2 open bugs, Regressed 1 open bug)
Details
(Whiteboard: dt-fission-m2-mvp)
Attachments
(3 files, 2 obsolete files)
For now, each panel does its own throttling, in order to prevent updating Redux/React/the DOM each time a new item is to be displayed.
- webconsole
https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/devtools/client/webconsole/webconsole-wrapper.js#310-325 - debugger
https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/devtools/client/debugger/src/utils/source-queue.js#14-38 - netmonitor
https://searchfox.org/mozilla-central/rev/76a83d0a218837ba6937d6a0fac51cb0008c2334/devtools/client/netmonitor/src/middleware/batching.js#30-58
We end up with slightly different algorithms, different delays, different behavior, different bugs. We would definitely benefit from having a single, shared implemented of it. It would also suddently benefit to other resources, which are not throttled (stylesheet? css changes?)
Also, while working on bug 1620280, I realized that the SourceQueue component of the debugger is subject to dead locks by calling itself, where a Source can end up dispatching new sources and make the debugger stop updating because of such dead lock.
Having a throttling in ResourceWatcher shouldn't be subject to such dead lock.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Listening to TRACK_CHANGE is tricky because of the new throttling,
as it can be merged intermittently.
So, here I try to wait for any action that can spawn a TRACK_CHANGE event.
Unfortunately, I have to contribute to generic helpers that aren't specific to ChangesView.
But if any test is using it, with the ChangesView, it may fix things.
Assignee | ||
Comment 2•4 years ago
|
||
Because of this, in netmonitor stubs tests, the resource objects ends up loosing
"intermediate" state and now contains all information that we gathered by the time
we emit throttled resources.
The only way to address that would be to do an archived copy of each resource state,
but I don't think we want to do that...
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
Assignee | ||
Comment 4•4 years ago
|
||
Comment 5•4 years ago
|
||
Comment on attachment 9175831 [details]
Bug 1663614 - Use same listener for NETWORK_EVENT and NETWORK_EVENT_STACKTRACE in order to guarantee event order.
Revision D90288 was moved to bug 1665709. Setting attachment 9175831 [details] to obsolete.
Comment 6•4 years ago
|
||
Tracking dt-fission-m2-mvp bugs for Fission Nightly milestone (M6c).
Assignee | ||
Comment 7•4 years ago
|
||
Updated•4 years ago
|
Comment 9•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/623937cef0c5
https://hg.mozilla.org/mozilla-central/rev/45e631b0acc8
https://hg.mozilla.org/mozilla-central/rev/eb56db9c8312
Description
•