Closed Bug 1847440 Opened 4 months ago Closed 4 months ago

getTextAtLineColumn causes Firefox to hang (astro dev)


(DevTools :: Inspector, defect, P2)

Firefox 117


(firefox118 fixed)

118 Branch
Tracking Status
firefox118 --- fixed


(Reporter: bugzilla, Assigned: emilio)




(5 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5.2 Safari/605.1.15

Steps to reproduce:

Inspected an element on a development version of a small Astro.js website.

This affects both Firefox and Firefox Developer Edition (117.0b3) on macOS. I can reproduce with a clean profile, and refreshing Firefox makes no difference.

Actual results:

Opening the inspector causes 100% CPU usage and an unresponsive UI while executing the regular expression in getTextAtLineColumn.

Expected results:

The inspector should open nearly instantly, selecting the target element ready for inspection.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
Component: DOM: Core & HTML → Inspector
Product: Core → DevTools

Thanks for filing!

I tried inspecting a few websites built with Astro.js, but could not reproduce the issue. Is there any way you can share your website with us?

Flags: needinfo?(bugzilla)

I've extracted the home page from my website and pushed it up to GitHub here:

I'm able to reproduce the issue when running in development. When I build the full site and push to Vercel, the problem goes away.

If you clone the repo, you can start up Astro with pnpm dev. The dev version should start up on port 3000.

Flags: needinfo?(bugzilla)

Thanks for sharing, will test your scenario!

Flags: needinfo?(jdescottes)

It seems that we are not computing the correct line number for the rules of the stylesheets used in this page. And then we end up trying to apply an invalid regex to extract the rule text.

It's not related to the stylesheet itself, because a static page using the same inline sheets doesn't show the same issue. I guess the hot reload mechanism used by astro/vite must confuse our helpers.

On DevTools side, the line number is computed at:

this.line = InspectorUtils.getRelativeRuleLine(this.rawRule);

And it returns a value which doesn't match the actual stylesheet. For instance, for a stylesheet which contains less than 1000 lines, it might return something above 1500, as if it was applying an offset.

I checked a bit the GetRelativeRuleLine implementation in InspectorUtils, and the lineNumber returned by aRule.GetLineNumber(); seems to have an offset and the value is wrong (eg 1895), but linkLineIndex0 is 0 so we don't manage to correct it.

Emilio, I can see there is already a comment about relative line numbers and dynamically inserted rules in this method. Do you think we might be hitting an edge case here?

Flags: needinfo?(jdescottes) → needinfo?(emilio)

I can repro and can look into what might be going on, but... Is this regex really the fastest way of getting the nth line?

Also, does DevTools use the line+column for something else than this? Because if not we could hand you the utf-8 byte offset (or even utf-16 code point, maybe) where the rule starts, which seems to be what you're trying to compute?

Flags: needinfo?(emilio) → needinfo?(jdescottes)
Flags: needinfo?(emilio)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

I can repro and can look into what might be going on, but... Is this regex really the fastest way of getting the nth line?

Also, does DevTools use the line+column for something else than this? Because if not we could hand you the utf-8 byte offset (or even utf-16 code point, maybe) where the rule starts, which seems to be what you're trying to compute?

It's probably not the best solution, it's been implemented quite a long time ago, and I don't think it was discussed much.
We could definitely use the offset for getTextAtLineColumn, and if it's correct it would fix the issue here.

From a quick check, we also use the line number to display it in the ruleview. (eg inline:1780) and clicking on this link jumps to the style editor at the specified line. So we would still need some way to compute the correct line.

Flags: needinfo?(jdescottes)

(Confirming since Julian and I have reproduced it)

Ever confirmed: true
Summary: getTextAtLineColumn causes Firefox to hang → getTextAtLineColumn causes Firefox to hang (astro dev)

If our line numbers etc are wrong, then we might throw and retry later.

Given the empty string already represents failure, make
getAuthoredCssText not throw and just return the empty string on

This avoids retrying over and over just to fail. It doesn't fix the
initial hang, but makes it more manageable.

Will still try to find a proper fix / root cause of course, but this
seems harmless enough either way.

Also expand canSetRuleText so that it's easier to reason about.

Assignee: nobody → emilio

CSS rules were storing absolute rather than relative line numbers (this
was done to match the old style system).

So when we hit the cached inline stylesheet code-path, for which we
share the CSS rules of the stylesheet, for the cache hit the line
numbers were completely off.

This particular page was probably regressed by bug 1834081, but the
issue could happen before with Shadow DOM.

Always store relative numbers and convert to absolute when asked by the
inspector, rather than the other way around.

This is simpler and makes the cache work.

Flags: needinfo?(emilio)

No need to explicitly return a promise in async functions.

Depends on D185916

Pushed by
Part 0: Split canSetRuleText so that it's easier to follow. r=nchevobbe,devtools-reviewers
Part 1: Cache failure in getAuthoredCssText(). r=nchevobbe,devtools-reviewers
Part 2: Simplify some callers now that getAuthoredCssText doesn't throw. r=nchevobbe,devtools-reviewers
Severity: -- → S3
Priority: -- → P2
Pushed by
Other misc cleanups in style-rule.js. r=nchevobbe,devtools-reviewers
Pushed by
Always store relative line numbers in CSS rules. r=zrhoffman
Pushed by
Fix line numbers in CSS error reports.
Pushed by
Fix expectation in browser_rules_media_queries now that constructable stylesheets use 1-based line numbers like everything else.

FYI, this patch (specifically fixed a bug related to incorrectly displayed properties inside rules.

My STR were:

  1. On
  2. Inspect the element with class .frame__corner--left-top
  3. In the Rules View look at the .frame__corner[data-v-7a211648] rule

It was displayed as

.frame__corner[data-v-7a211648] {
  height: 1015px;
  position: relative;

Now it's correctly displayed as

.frame__corner[data-v-7a211648] {
  position: absolute;
  width: 24px;
  height: 24px;
  background-image: url(/svg/corner.svg);
  background-size: contain;
  background-position: 50%;

(Wanted to file a bug for that but saw that it was already fixed in Nightly. So, running mozregression then brought me here.)


QA Whiteboard: [qa-118b-p2]
See Also: → 1867816
You need to log in before you can comment on or make changes to this bug.