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.

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

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.

Hey, sorry but that is ETA on this?

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.

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.

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

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

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.

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

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.