Workaround 1Password browser extension bug #1932
Open
+27
−16
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
preview on auspice.us, nextstrain.org
Description of proposed changes
The bug pathologically slows down (and sometimes crashes) pages with thousands/millions of SVG elements in the DOM, which happens in reasonably sized datasets.¹
Short circuit the extension's calls to the very slow .innerText in its function:
by nesting each panel's D3 elements deeper than extension's traversal limit of 4. That is, we're moving the closest HTMLElement (e.g. <div>s containing <svg>s) further away from the leaf SVG elements.
For most panels, fewer <g>s would do, but adding four guards against future changes to D3 implementation.
The workaround was trivial for entropy and frequencies panels which already have a separation where size/styles are applied on a parent <svg> and D3 operations happen on a child <g>. It was still not too bad for map and measurements panels - those did not have a pre-existing separation, but adding the separation was trivial.
The tree panel was the least trivial - the code and type annotations assumed that the root SVG element for D3 operations was an <svg>, so switching it to <g> required updating those assumptions. Additionally, there is code that retrieves the width/height from the root SVG element, so it must be retained on the child element even when nested under an <svg>, which requires width and height to be set explicitly.
¹ #1919
Related issue(s)
#1919
Checklist