The NetworkThrottling menu [component and its Redux action/reducer](https://searchfox.org/mozilla-central/source/devtools/client/shared/components/throttling) were extracted from Netmonitor to be reused in the Responsive Design Mode. Theoretically, dispatching the [shared action](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/shared/components/throttling/actions.js) should keep the component in sync. However, the action is actually dispatched to two separate stores, one for [RDM](https://searchfox.org/mozilla-central/source/devtools/client/responsive.html/index.js#43) and one for [Netmonitor](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/netmonitor/src/api.js#40). Because of this, they are out of sync. A one-way sync could have been established by leveraging [Netmonitor's API](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/netmonitor/src/api.js), requested via the [toolbox.getNemonitorAPI()](https://searchfox.org/mozilla-central/source/devtools/client/framework/toolbox.js#3235), and listening for the [network throttling change event](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/netmonitor/src/connector/firefox-connector.js#396). Additionally, the RDM could directly call this API to set the throttling instead of calling the corresponding methods on [EmulationFront](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/responsive.html/manager.js#690-710). However, that doesn't seem possible. The RDM is not connected to the Toolbox, therefore it can't get a reference to the Netmonitor API. The [EmulationFront](https://searchfox.org/mozilla-central/source/devtools/shared/fronts/emulation.js#12)/[EmulationActor](https://searchfox.org/mozilla-central/source/devtools/server/actors/emulation.js#25) seems to be the shared bit between the two panels. One way I see to solve this bug is to extend that to fire an event whenever the [throttling pref is set](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/server/actors/emulation.js#108-139), listen to that event in both the Netmonitor and RDM clients, then dispatch the action to each of their Redux stores to sync the NetworkThrottlingMenu components. Of course, if there's a practical way to connect the RDM to the Toolbox (though, I'm not sure that's feasible or desired), the issue could be solved by using the Netmonitor API as described above. Pinging Gabriel and Honza who have more insight into the two panels to sanity-check the proposals above. I'm open to other ideas too.
Bug 1531642 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The NetworkThrottling menu [component and its Redux action/reducer](https://searchfox.org/mozilla-central/source/devtools/client/shared/components/throttling) were extracted from Netmonitor to be reused in the Responsive Design Mode (aka RDM). Theoretically, dispatching the [shared action](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/shared/components/throttling/actions.js) should keep the component in sync. However, the action is actually dispatched to two separate stores, one for [RDM](https://searchfox.org/mozilla-central/source/devtools/client/responsive.html/index.js#43) and one for [Netmonitor](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/netmonitor/src/api.js#40). Because of this, they are out of sync. A one-way sync could have been established by leveraging [Netmonitor's API](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/netmonitor/src/api.js), requested via the [toolbox.getNemonitorAPI()](https://searchfox.org/mozilla-central/source/devtools/client/framework/toolbox.js#3235), and listening for the [network throttling change event](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/netmonitor/src/connector/firefox-connector.js#396). Additionally, the RDM could directly call this API to set the throttling instead of calling the corresponding methods on [EmulationFront](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/responsive.html/manager.js#690-710). However, that doesn't seem possible. The RDM is not connected to the Toolbox, therefore it can't get a reference to the Netmonitor API. The [EmulationFront](https://searchfox.org/mozilla-central/source/devtools/shared/fronts/emulation.js#12)/[EmulationActor](https://searchfox.org/mozilla-central/source/devtools/server/actors/emulation.js#25) seems to be the shared bit between the two panels. One way I see to solve this bug is to extend that to fire an event whenever the [throttling pref is set](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/server/actors/emulation.js#108-139), listen to that event in both the Netmonitor and RDM clients, then dispatch the action to each of their Redux stores to sync the NetworkThrottlingMenu components. Of course, if there's a practical way to connect the RDM to the Toolbox (though, I'm not sure that's feasible or desired), the issue could be solved by using the Netmonitor API as described above. Pinging Gabriel and Honza who have more insight into the two panels to sanity-check the proposals above. I'm open to other ideas too.
The NetworkThrottling menu [component and its Redux action/reducer](https://searchfox.org/mozilla-central/source/devtools/client/shared/components/throttling) were extracted from Netmonitor to be reused in the Responsive Design Mode (aka RDM). Theoretically, dispatching the [shared action](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/shared/components/throttling/actions.js) should keep the component in sync. However, the action is actually dispatched to two separate stores, one for [RDM](https://searchfox.org/mozilla-central/source/devtools/client/responsive.html/index.js#43) and one for [Netmonitor](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/netmonitor/src/api.js#40). Because of this, they are out of sync. A one-way sync could have been established by leveraging [Netmonitor's API](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/netmonitor/src/api.js), requested via the [toolbox.getNemonitorAPI()](https://searchfox.org/mozilla-central/source/devtools/client/framework/toolbox.js#3235), and listening for the [network throttling change event](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/netmonitor/src/connector/firefox-connector.js#396). Additionally, the RDM could directly call this API to set the throttling instead of calling the corresponding methods on [EmulationFront](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/client/responsive.html/manager.js#690-710). However, that doesn't seem possible. The RDM is not connected to the Toolbox, therefore it can't get a reference to the Netmonitor API. The [EmulationFront](https://searchfox.org/mozilla-central/source/devtools/shared/fronts/emulation.js#12)/[EmulationActor](https://searchfox.org/mozilla-central/source/devtools/server/actors/emulation.js#25) seems to be the shared bit between the two panels. One way I see to solve this bug is to extend that to fire an event whenever the [throttling pref is set](https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/devtools/server/actors/emulation.js#108-139), listen to that event in both the Netmonitor and RDM clients, then dispatch the action to each of their Redux stores to sync the NetworkThrottlingMenu components. Of course, if there's a practical way to connect the RDM to the Toolbox (I'm not sure if that's feasible or desired), the issue could be solved by using the Netmonitor API as described above. Pinging Gabriel and Honza who have more insight into the two panels to sanity-check the proposals above. I'm open to other ideas too.