Closed Bug 1943351 Opened 1 month ago Closed 27 days ago

Visibility change handler shouldn't force react render but only freeze redux updates on panel hiding

Categories

(DevTools :: Framework, defect, P3)

defect

Tracking

(firefox137 fixed)

RESOLVED FIXED
137 Branch
Tracking Status
firefox137 --- fixed

People

(Reporter: ochameau, Assigned: ochameau)

References

Details

(Keywords: perf-alert)

Attachments

(3 files)

Right now the VisibilityHandler code, when the panel is hidden, only hold off React updates via React.shouldComponentUpdate:
https://searchfox.org/mozilla-central/rev/5b061cdc4d40d44988dc61aa941cfbd98e31791f/devtools/client/shared/components/VisibilityHandler.js#38-40
while this prevent most of the computations, all connected components get their mapStateToProps being called.
I think this is what later justifies to use React.forceUpdate as their props may already be updated while the panel was hidden.
https://searchfox.org/mozilla-central/rev/5b061cdc4d40d44988dc61aa941cfbd98e31791f/devtools/client/shared/components/VisibilityHandler.js#48

Ideally, we should be holding off execution at an higher level: redux and the connect/mapStateToProps functions.
While the panel are hidden, Redux connect shouldn't call any of the connected component's mapStateToProps methods.
This would prevent any React updates as it would prevent changing any component props.
Once we manage to do that, the update on panel being shown is simple: force a store state change and resume calling the mapStateToProps methods.
With such setup, the React component would switch from the state of props while the panel was last visible, to updated props when the panel is re-shown. Everything should be updating efficiently based on redux and react diffing algorithms.

Blocks: 1943364
Assignee: nobody → poirot.alex
Status: NEW → ASSIGNED
No longer blocks: 1943364
Depends on: 1943543
Severity: -- → S3
Priority: -- → P3
Attachment #9461324 - Attachment description: Bug 1943351 - [devtools] Hold off all redux updates when panels are hidden. → Bug 1943351 - [devtools] Hold off all redux updates when netmonitor is hidden.

We were hiding it via some late action fired while the panel was already hidden.
This help fix browser_jsterm_autocomplete_mapped_variables.js which was failing
because of the popup consuming the click event when switching to the debugger.

Pushed by apoirot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9ad9f4004de4 [devtools] Hold off all redux updates when netmonitor is hidden. r=devtools-reviewers,nchevobbe https://hg.mozilla.org/integration/autoland/rev/d958cc2493a6 [devtools] Also avoid uncessary redux updates when the console is hidden. r=devtools-reviewers,nchevobbe https://hg.mozilla.org/integration/autoland/rev/bdf540812b20 [DevTools] Hide the console autocomplete popup when opening another panel. r=devtools-reviewers,jdescottes,nchevobbe

Backed out for causing bc failures @browser_ext_devtools_panel.js.

Flags: needinfo?(poirot.alex)
Pushed by apoirot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e05b8223d353 [devtools] Hold off all redux updates when netmonitor is hidden. r=devtools-reviewers,nchevobbe https://hg.mozilla.org/integration/autoland/rev/1112744717ae [devtools] Also avoid uncessary redux updates when the console is hidden. r=devtools-reviewers,nchevobbe https://hg.mozilla.org/integration/autoland/rev/0650029a3ec3 [DevTools] Hide the console autocomplete popup when opening another panel. r=devtools-reviewers,jdescottes,nchevobbe
Status: ASSIGNED → RESOLVED
Closed: 27 days ago
Resolution: --- → FIXED
Target Milestone: --- → 137 Branch
See Also: → 1946690

(In reply to Serban Stanca [:SerbanS] from comment #11)

https://hg.mozilla.org/mozilla-central/rev/e05b8223d353
https://hg.mozilla.org/mozilla-central/rev/1112744717ae
https://hg.mozilla.org/mozilla-central/rev/0650029a3ec3

Perfherder has detected a devtools performance change from push 0650029a3ec3ced370663cd51701c62a77383337.

Improvements:

Ratio Test Platform Options Absolute values (old vs new)
59% damp custom.netmonitor.manyrequests.togglepanel windows11-64-shippable-qr e10s fission stylo webrender 475.48 -> 193.68
45% damp custom.netmonitor.manyrequests.togglepanel macosx1470-64-shippable e10s fission stylo webrender 813.06 -> 446.28
37% damp custom.netmonitor.manyrequests.togglepanel linux1804-64-shippable-qr e10s fission stylo webrender 1,067.73 -> 668.36
29% damp custom.netmonitor.bigdatarequests.navigate.DAMP macosx1470-64-shippable e10s fission stylo webrender 2,405.91 -> 1,708.03
26% damp custom.netmonitor.bigdatarequests.requestsFinished.DAMP macosx1470-64-shippable e10s fission stylo webrender 2,626.78 -> 1,942.94
... ... ... ... ...
4% damp browser-toolbox.styleeditor-ready.DAMP windows11-64-shippable-qr e10s fission stylo webrender 284.99 -> 274.12

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

You can run these tests on try with ./mach try perf --alert 43786

For more information on performance sheriffing please see our FAQ.

Keywords: perf-alert
Blocks: 1946690
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: