fix: avoid while cycle in computeMaxFontSize for big Number run forever when css !important rule applied

[Gwitchr]

SUMMARY

adding custom CSS to a dashboard with a bigInt chart would activate a while loop that didn't ever finished, which somehow wasn't caught by the surrounding ErrorBoundary cause the whole app crashed before running out of memory (my guess)

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Screen.Recording.2022-05-13.at.17.04.16.mov

TESTING INSTRUCTIONS

1. Create a Dashboard.
2. Access it on edit mode.
3. Click on the three ellipses on the top right corner > Edit CSS.
4. Add below CSS code to it:

.header-line {
font-size: 170px!important;
}

5. Add a Big Number Chart to the Dashboard.

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[codecov]

Codecov Report

Merging #20067 (660b6ad) into master (62e1c34) will increase coverage by 0.00%.
The diff coverage is 40.00%.

@@           Coverage Diff            @@
##           master   #20067    +/-   ##
========================================
  Coverage   66.28%   66.29%            
========================================
  Files        1712     1714     +2     
  Lines       63968    64116   +148     
  Branches     6731     6796    +65     
========================================
+ Hits        42404    42506   +102     
- Misses      19853    19879    +26     
- Partials     1711     1731    +20     

Flag	Coverage Δ
javascript	51.35% <40.00%> (+0.07%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...perset-ui-core/src/dimension/computeMaxFontSize.ts	86.95% <40.00%> (-13.05%)	⬇️
superset-frontend/src/reports/reducers/reports.js	38.09% <0.00%> (-36.91%)	⬇️
...charts/src/Timeseries/Regular/Bar/controlPanel.tsx	34.48% <0.00%> (-5.52%)	⬇️
...d/src/explore/components/PropertiesModal/index.tsx	63.93% <0.00%> (-4.92%)	⬇️
...rset-frontend/src/components/ReportModal/index.tsx	78.33% <0.00%> (-4.21%)	⬇️
...end/src/components/Datasource/DatasourceEditor.jsx	65.20% <0.00%> (-4.17%)	⬇️
...frontend/src/dashboard/components/Header/index.jsx	56.80% <0.00%> (-4.13%)	⬇️
...onalFormattingControl/FormattingPopoverContent.tsx	51.35% <0.00%> (-2.94%)	⬇️
...dashboard/components/SliceHeaderControls/index.tsx	63.85% <0.00%> (-2.40%)	⬇️
...plugins/plugin-chart-echarts/src/utils/forecast.ts	93.22% <0.00%> (-1.61%)	⬇️
... and 66 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 62e1c34...660b6ad. Read the comment docs.

[stephenLYZ]

Thanks for the fix! It looks like the codecov didn't pass, so I'm guessing we might need to add some branch tests for this function.

[villebro]

IIRC, @kgabryje already fixed a related problem in #19688 - I wonder if this additional check is still needed?

[kgabryje]

Thanks for tagging me Ville! My fix doesn't cover the scenario presented by @Gwitchr, so I think this should go in.
I just wonder if we could break the loop quicker - instead of decrementing to below 0, maybe we could do a check like "if the size for font size x is the same as the size for x-1, return x". Wdyt?

[kgabryje]

Also, it would be great to implement binary search for optimal font size instead of decrementing by 1 to improve performance, but that's definitely out of scope of this PR 🙂

Anyway, if the proposal from comment above is not viable or would require a large refactor, let's merge this fix (which is great!) and iterate on this later

[kgabryje]

Replaced by #20173