1520729 - jetbrains "upsource" file-view hangs the browser, when scrolled

Status: NEW

(Core :: Layout, defect, P2)

Description

[maggus.staab]

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

Steps to reproduce:

opening a page within our internal code review tool freezes the browser
(a toolbar appear which allows to "stop" running scripts or "wait" for them to finish).

please find the following performance profile
https://perfht.ml/2DfVU1G

Actual results:

browser got stuck and clicking "wait" did not make the app responsive.
it seems things got so slow that the toolbar shows up again and again

Expected results:

things should work fluid, like it does in chrome

Comment 1

[maggus.staab]

Attachment: grafik.png

Comment 2

[Kanchan Kumari QA]

Hello Mike, Can you please look into the performance profile? Thanks!

Comment 3

[Mike Conley (:mconley) (:⚙️) (PTO June 8 - 12)]

It looks like some JS on the page is causing layout flushes on every scroll event:

https://perfht.ml/2WaF7Ve

This is pretty awful - for about 13 seconds, the main thread seems to be caught handling a scroll event, style flushing, reflowing, and repeating.

If Chrome or other browsers behave better on this site, then perhaps there's an optimization here that we're missing.

If I'm reading this correctly, then in the marker chart, there's a single scroll event that's causing us to enter this layout thrashing loop.

I'm putting it in Layout for now, and queueing for qf triage.

Comment 4

[Daniel Holbert [:dholbert]]

It looks like the tool might be downloadable for free (limited to 10 users per instance) here:
https://www.jetbrains.com/upsource/download/#section=linux
Direct link: https://download.jetbrains.com/upsource/upsource-2018.2.1154.zip

I'll download it and see if I can reproduce, so we can (hopefully) investigate further.

Also, maggus.staab: if you can provide any more information about what sorts of things I might need to do to trigger the issue after setting up a brand-new fresh instance (i.e. which pages trigger the issue), that'd be appreciated! (also: thanks for the report!)

Comment 5

[Daniel Holbert [:dholbert]]

Also: do you know if this happened to get slow only recently, vs. whether it's been slow in Firefox forever as far as you know?

Comment 6

[maggus.staab]

As far as I remember the problem only exists since the last update.

I will check whether chrome acts as bad as FF.

Comment 7

[Daniel Holbert [:dholbert]]

In your profile in comment 0, it looks like the hang is in "EventDispatcher::Dispatch scroll" -- i.e. we're churning when running the page's JS scroll-handler. Here's the profile with the relevant track & filtered for that phrase:
https://perfht.ml/2R6WdiN
(It seems to be responsible with 5.8 seconds of jank, during this 16-second period where we're unresponsive.)

Could you confirm whether it's specifically scrolling that causes the hang here? (rather than e.g. pageload) In other words, if you load a review page and don't scroll at all, does the load happen OK without noticeable hangs? (If not: could you attach a profile of that process?)

On my end: I've got an upsource instance configured (having imported https://github.com/mozilla-iot/gateway/ as a "dummy repo" and using one of its pull requests as a review testcase). I do see a slight bit of jank when scrolling, and it seems to be associated with adding "position:fixed" to a header type element (to emulate a "sticky position" behavior), but it's not very long.

Comment 8

[Daniel Holbert [:dholbert]]

For reference/comparison, here's a profile of what I'm seeing locally when loading a review page in Firefox (extends from 1s-5s in this profile) and then scroll it (very brief, happens around ~9.5s in this profile): https://perfht.ml/2WbmBvS

Both do look a little slow in this profile, but they're nowhere near the level of jank in the profile in comment 0. (And we do repaint periodically during the multisecond page load.)

Comment 9

[Daniel Holbert [:dholbert]]

In my Upsource instance's case, the most interesting thing (perf-wise) that happens in the page's scroll event-handler is:

• they add the class "sidebar_fixed" to the left sidebar, which contains the list of all the affected files.
• this causes that element to become "position:fixed (if your viewport is more than 1024px wide - the relevant CSS rule is inside of a viewport-size-dependent media query).
• ...and that causes us to rebuild frames for that element and its whole subtree (that's what we do for changes to the 'position' property). And that could be quite a lot of rebuilding, if there are a lot of elements in that sidebar. (E.g. a lot of files touched in the patch that's undergoing review.)

I simulated "lots of stuff in that sidebar" scenario by copypasting the contents of the sidebar ~5x, and I verified that the scroll handler got progressively jankier when I did that. (246ms restyles on scroll, largely spent in frame reconstruction)

However, I don't think this is actually what was going on in the reporter's original profile, because that one has most of its time spent in many many short restyles/reflows, in response to (a) setting the "top" property and (b) Node.removeChild() calls...

So, Maggus: I'm quite curious if there's anything that you can determine about whether only particular review pages cause it, and if so, what sorts of characteristics those reviews have (many files touched vs. many review comments present, vs. something else). And, per comment 7, I'm also curious if the jank only starts when you scroll (as looks to be the case from your profile).

Comment 10

[maggus.staab]

I can confirm that the yank only occurs when scrolling. Just loading the file within question doesnt yank without scrolling.

I guess in my case „upsource“ is starting to load additional file content (and maybe does some code analysis).
I have a php project configured with „code intelligence, if it matters.