1623988 - Freezes on inspect html and when html node is opened

Status: RESOLVED FIXED

(DevTools :: Inspector, defect, P2)

Description

[piotr.b.kozuchowski]

Attachment: Salesforce.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

I'm trying to inspect HTML in Salesforce Lightning Experience or expand node in inspector afterwards.
I'm attaching saved page for debuging, although I think the freeze is much longer while online.
I'm open for sharing screen online to show you the issue if needed.

Actual results:

When inspector is opened or every time a node is expanded, entire Firefox freezes for about 10 seconds. Since I'm developer, I had to resign from using Firefox for that reason. This is also true for Firefox for Developers editions.

Expected results:

I'd expect the action to be instantaneous. It is in Google Chrome or other browsers.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Patrick Brosset <:pbro>]

Thank you so much for filing this bug with the test case. I was able to reproduce immediately the issue.
My impression is that this is coming from the Rules panel.
In this panel, there is a single rule (selector :root) which contains more than 1400 declarations. These declarations are CSS variables.

I recorded a profile to show this: https://perfht.ml/39a3E1S

It shows that this particular function is to blame: hasCSSVariable
https://searchfox.org/mozilla-central/rev/202a285024f174c2d2bf2152d9cba90a03723eab/devtools/client/inspector/rules/utils/utils.js#292

If I remove the giant rule from the test file, performance becomes acceptable again.

Comment 3

[piotr.b.kozuchowski]

Hey, sorry but that is ETA on this?

Comment 4

[Razvan Caliman [:rcaliman]]

Hi Piotr,

No ETA yet. But it is on our radar.

The issue stems from the massive CSS rule with a lot of CSS Custom Properties. Whenever one of them changes, the entire list must be checked for things like overwritten or inherited properties. This freeze happens because that is a complex operation done on a dataset much larger than anticipated.

We need to optimize this part of the code, but do so carefully.

Comment 6

[Razvan Caliman [:rcaliman]]

A very handy way to reproduce this on a live site is inspecting youtube.com (from bug 1631520)

Steps to reproduce:

• Navigate to youtube.com
• Right-click an element and pick Inspect Element
• Wait for the DevTools Inspector to open and the element to be marked as selected in the markup panel

Expected
Action happens quickly

Actual Result
It takes a very long time for the DevTools to open and show the selected element and its CSS rules

---

YouTube loads some very heavy stylesheets. Some contain more than 7800 CSS rules with a lot of CSS variables, mostly declared at the :root level. Because every node can inherit any of those root-level variables, the Rules panel needs to render and resolve all of them, for example to check whether they're overwritten. That itself is not a cheap operation, but it's exacerbated by the very large number of applicable CSS variables.

Comment 7

[Razvan Caliman [:rcaliman]]

Attachment: Bug 1623988 - Extract CSS variables used in a CSS declaration for quick reference

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0165080b158d
Extract CSS variables used in a CSS declaration for quick reference r=jdescottes

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/0165080b158d

Comment 11

[Treycos]

If this is of any help, here is the result of the mozregression bisection :

Mozregression results

Before this commit, the delay after clicking/expanding a node was about .5 to 1 sec, after that it got up to 3-6 seconds while completely freezing Firefox

Comment 12

[gwarser]

For me it's difference between 1-2 and 5-7 seconds.

77:28.73 INFO: Narrowed integration regression window from [ded87cc3, 05d6c88b] (3 builds) to [0a1a438c, 05d6c88b] (2 builds) (~1 steps left)
77:28.73 INFO: No more integration revisions, bisection finished.
77:28.73 INFO: Last good revision: 0a1a438c807e04f0c660bb12a711257e5a96fed8
77:28.73 INFO: First bad revision: 05d6c88bc181c358a228b5249147e3bf543d916d
77:28.73 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0a1a438c807e04f0c660bb12a711257e5a96fed8&tochange=05d6c88bc181c358a228b5249147e3bf543d916d

And it's 1-2s in current Nightly now.

Comment 13

[piotr.b.kozuchowski]

It's a bit better, but still noticably slower than Chrome. Firefox seems to freeze every time HTML node is expanded or collapsed too.

Comment 14

[Julian Descottes [:jdescottes]]

Hi piotr.b.kozuchowski.

Since we already landed a fix linked to this bug, let's keep it closed.
Further performance improvements are tracked & discussed in the follow-up bug 1686240

Firefox seems to freeze every time HTML node is expanded or collapsed too.

This is probably because we are selecting nodes when clicking on the expand/collapse toggle.
Changing this behaviour is tracked by Bug 1686241, and we should go forward with it soon.