1659971 - Firefox UI freezes on some azure devops pages

Status: RESOLVED INVALID

(Core :: JavaScript Engine: JIT, defect, P2)

Description

[Andrei Petcu]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

I just visited an azure devops page. https://yourcompany.visualstudio.com/SomeBuildId

Actual results:

The UI just froze and I got the yellow bar with the message to wait or to stop the script. Here is a profile. https://share.firefox.dev/2QjXUfb

Expected results:

The UI should work and the page should not freeze

Comment 1

[Andrei Petcu]

The above sample is from Firefox Nightly ASAN. I disabled all my extensions and created a new profile https://share.firefox.dev/2Ee4rVV
I saw this issue on DevEdition v80 also.

Comment 2

[Andrei Petcu]

Firefox stable has the same issue. I have no extensions or customizations in this profile, just a theme. It's the official Mozilla flatpak build https://share.firefox.dev/3kSnJ3M

Comment 3

[Andrei Petcu]

Attachment: about.support.json

Comment 4

[Andrei Petcu]

I know I'm not offering steps to reproduce but I'm willing to build Firefox from sources and have a remote session where I can give a Firefox dev full control over my machine. You can install whatever tools you need.

Comment 5

[Jan de Mooij [:jandem]]

Thanks for the bug report.

Some questions:

• How fast does this load in another browser? I'm wondering if (a) the page is slow (and maybe a bit slower in Firefox) or (b) if it's really a Firefox-specific issue somewhere (either the JS on the page or in Firefox).
• Do you know if this is a recent regression?

Comment 6

[Jan de Mooij [:jandem]]

Also: is the page really frozen or does the slow-script bar eventually disappear? If the page does finish loading, how long does it take?

Probably most useful to test this in a non-ASan build.

Comment 7

[Andrei Petcu]

It's heavy in Chrome also but the Chrome UI never freezes. It's always usable in Chrome.
I can check in ESR. Not sure if it's a regression but it's the same in stable, dev ed and nightly.
It freezes for a few seconds but it becomes responsive again.

Comment 8

[Nicolas B. Pierron [:nbp]]

Looking at the o function, which is one of the 2 biggest JS function in terms of consumed time.
It seems that we might be missing a case for an Inline Cache both in Baseline and in Ion.

Baseline calls SetObjectElementWithReceiver for 23% of the execution of the o function.

And Ion IC seems to fail to attach anything, in both js::jit::IonSetPropertyIC::update and js::jit::IonGetIteratorIC::update. It might also be possible that Ion IC have an issue with the repeated GCs, as they are discarded on GCs.

o(e,t,n){
  var r, i = {}, o = null, a = null;
  if (null != t)
     for(r in void 0 !== t.ref && (a=t.ref), void 0 !== t.key && (o = "" + t.key), t)
        Q.call(t,r) && !B.hasOwnProperty(r) && (i[r]=t[r]);
  var l = arguments.length - 2;
  if (1 === l)
     i.children = n;
  else if(1 < l) {
    for(var u = Array(l), s = 0; s < l; s++)
       u[s] = arguments[s + 2];
    i.children = u
  }
  if(e && e.defaultProps)
    for(r in l = e.defaultProps)
       void 0 === i[r] && (i[r] = l[r]);
  return {
     $$typeof: T,
     type: e,
     key: o,
     ref: a,
     props: i,
     _owner: q.current
  }
}

Comment 9

[Iain Ireland [:iain]]

It looks like we're falling off some sort of performance cliff. It would be interesting to see if this is still a problem in Warp.

Would it be possible for you to set javascript.options.warp to true, restart your browser, and visit the page again? (This will require a relatively recent version of Nightly.)

Comment 10

[Andrei Petcu]

I switched to NIghtly, flipped the flag and tested again. It does not happen every time but I will report here if this will come back.

Comment 11

[Andrei Petcu]

I still get the notification with javascript.options.warp set to true. I have an ASAN build if that matters, might be a bit slower. Also, I have fission enabled in Nightly and the UI does not freeze, just the page content freezes https://share.firefox.dev/3mmV9bJ

Comment 12

[Andrei Petcu]

Here is a "normal nightly" so no ASAN build, no fission and warp. It's one of my profiles, not a fresh profile. It has some extensions. Same issue but now I don't see the FF UI freeze, just the dom in the page freezes. https://share.firefox.dev/35BBONU

Can I help with any other info Iain? As I said, I'm open to a remote debug session. I can do custom builds with patches from Phabricator. I know how much it sucks when there are issues with private pages user can't share credentials with the Firefox devs.

Comment 13

[Iain Ireland [:iain]]

It looks like that profile was taken with Warp disabled. Maybe you turned it off by mistake? I see some bailouts in the marker table with BailoutKind::TypeBarrier, which shouldn't exist for Warp. I also see a few samples in IonBuilder and none in WarpBuilder.

Taking a step back: it looks like roughly all of the time is being spent in onValueChanged. Based on the name of the source file (https://cdn.vsassets.io/ext/ms.vss-features/ui-core-content/ms.vss-features.ui-core-content.es6.LOkvHOIQMYpDPkvs.min.js) and the presence of _reactInternalFiber, it looks like it's part of some React-based UI framework. If the same hang is not present in Chrome, I can see two possibilities: either V8 is doing a better job on these callbacks, or we're triggering the changes more often. (Any more information you could give about the relative performance of FF vs Chrome would be helpful.)

Overall, this profile looks relatively flat. It's unlikely that any individual JIT optimization will be a silver bullet. The biggest opportunity I can see is that almost 4% of the samples are in Object.assign. We have bug 1648546 open to optimize that in CacheIR, but even if we optimized it down to nothing, 96% of a slow script warning is still probably a slow script warning. (Also, that optimization is more effective post-Warp.)

This is the sort of code where Warp is plausibly an improvement, so it's likely good news that this latest profile isn't Warp. I'd be interested in seeing if you can still replicate the hang with Warp turned on. Beyond that, I wonder if there's a way to compare the number of onValueChanged events in FF vs Chrome, to see whether we're doing more work.

Comment 14

[Andrei Petcu]

I managed to make it be slow in Chrome also. Not sure why in my initial testing Chrome was doing better.
I'll close it. Thank you for looking into this issue. Sorry for the wasted time.