1663614 - Throttle ResourceWatcher events on the client side

Status: RESOLVED FIXED

(DevTools :: Framework, enhancement)

Description

[Alexandre Poirot [:ochameau]]

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.

Comment 1

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1663614 - Listen to each individual TRACK_CHANGE event.

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.

Comment 2

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1663614 - Throttle resources on the client side from ResourceWatcher.

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...

Comment 3

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1663614 - Do not use EventEmitter API in ResourceWatcher.

Comment 4

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1663614 - Use same listener for NETWORK_EVENT and NETWORK_EVENT_STACKTRACE in order to guarantee event order.

Comment 5

[Phabricator Automation]

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

[Chris Peterson [:cpeterson]]

Tracking dt-fission-m2-mvp bugs for Fission Nightly milestone (M6c).

Comment 7

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1663614 - Wait for state instead of TRACK_CHANGE events.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/623937cef0c5
Do not use EventEmitter API in ResourceWatcher. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/45e631b0acc8
Throttle resources on the client side from ResourceWatcher. r=jdescottes,bomsy
https://hg.mozilla.org/integration/autoland/rev/eb56db9c8312
Wait for state instead of TRACK_CHANGE events. r=bradwerth

Comment 9

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/623937cef0c5
https://hg.mozilla.org/mozilla-central/rev/45e631b0acc8
https://hg.mozilla.org/mozilla-central/rev/eb56db9c8312