1753667 - Firefox hangs loading github PR page

Status: UNCONFIRMED

(Core :: Layout: Text and Fonts, defect, P3)

Description

[joshuasend1]

Attachment: Screen Shot 2022-02-04 at 2.54.38 PM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

1. Updated firefox to 96
2. loaded a length PR to view the file difference. I was working on: https://github.com/vaticle/typedb/pull/6512/files

Further information:

• I'm signed into github
• I'm using "split view" on the files page
• reproducible in regular mode with addons disabled, and in troubleshooting mode
• Using MacOS Big Sur 11.6.1

Actual results:

Page loads for a long time. It does eventually finish after a few minutes. However, firefox in the meantime pops up a notification:
"This page is slowing down Firefox. To speed up your browser, stop this page."

Screenshot has been added showing this notification.

Expected results:

Expected the page to load < 1 second. This worked in older versions of Firefox, and works fine in Safari/Chrome.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

I can't reproduce this, off-hand. https://github.com/vaticle/typedb/pull/6512/files?diff=split&w=0 loads pretty fast. Is there any chance you could:

• Go to profiler.firefox.com.
• Enable the profiler button, and start recording.
• Reproduce the issue.
• Stop recording. This should open the profile viewer.
• Click "Upload local profile" at the top right of the profiler.
• Paste the URL here.

That'd be immensely helpful in figuring this out.

Comment 3

[Daniel Holbert [:dholbert]]

I do see a several-seconds-long hang in Firefox when I load that page in GitHub, after I scroll to the bottom of the page (e.g. if I press "End" on my keyboard). GitHub seems to be doing some lazy-load processing to show more of the diff, which locks us up for a bit.

Here's a profile of what I see, for reference:
https://share.firefox.dev/3GzzyWs
There's about 9 seconds of jank in the middle here (though on the plus side, we are reliably painting GitHub's throbber/spinner animation during this time, to indicate that something is happening.)

Note, I only get this jank if I'm logged in to GitHub. If I'm not logged in, then GitHub presumably renders different content that happens to be not as expensive to set up.

Comment 4

[Daniel Holbert [:dholbert]]

I see a similar hang in Chrome (similar to the one I see in comment 3), if I perform the same steps (be logged into github, load the URL, scroll to the end of the page, notice throbber spinning for ~8-10 seconds, during which time the tab is not responsive to user input e.g. clicks/text-selection).

So: I do see something like what was reported, but it reproduces in multiple browsers -- not just Firefox -- and it seems to be due to GitHub just performing a lot of synchronous work in JS all at once. So, my profile from comment 3 isn't especially-useful except to demonstrate what GitHub is doing (which seems to be slow regardless of browser).

(In reply to joshuasend1 from comment #0)

Expected the page to load < 1 second. This worked in older versions of Firefox, and works fine in Safari/Chrome.

To clarify: is it still faster in those other browsers if you're logged in to GitHub? And are you sure you're testing with the same steps there? (I assume in Firefox you're triggering the GitHub lazy-load-the-bottom-of-the-diff behavior, perhaps by scrolling to near the end of the page, or maybe something else).

Also, it is notable that your reported load time (minutes) is much longer than what I'm seeing, so a profile would still definitely be handy, per emilio's comment! Though, that's perhaps unnecessary if you discover that other browsers do in fact trigger a similar hang when tested under the exact same conditions, since that would indicate it's an issue on GitHub's side.

Comment 5

[joshuasend1]

Hi there - sorry for the delay.

I've uploaded a profile at https://bugzilla.mozilla.org/show_bug.cgi?id=1753667, I hope it is helpful. Pretty big!

I did have to scroll down to the bottom of the page, and then scroll back up to the top - which causes the rendering to freeze for about 80 seconds (screenshots attached). After that it is still a bit laggy but more acceptable.

I switched to Chrome and tried and in fact do find it hangs with the extra two steps above. This indicates Github changed something recently that causes this -- I'll probably file an issue with them too.

I think I probably didn't spot it in chrome in my initial test because the page was still rendered (though "not responsive"). In firefox the page rendering freezes and is unresponsive. Hopefully it is useful in some way to the firefox team!

Comment 6

[Emilio Cobos Álvarez (:emilio)]

(In reply to joshuasend1 from comment #5)

Hi there - sorry for the delay.

No problem!

I've uploaded a profile at https://bugzilla.mozilla.org/show_bug.cgi?id=1753667, I hope it is helpful. Pretty big!

Wrong link?

Comment 7

[joshuasend1]

Right - here you go! https://share.firefox.dev/3uwBsEF

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to joshuasend1 from comment #5)

I did have to scroll down to the bottom of the page, and then scroll back up to the top - which causes the rendering to freeze for about 80 seconds (screenshots attached). After that it is still a bit laggy but more acceptable.

Thanks! Yikes, 86 seconds of jank is terrible (but unfortunately, totally possible if a page does enough work without yielding; that's why we offer the "stop this page" button, as a way to halt whatever the page is doing).

During the shorter-hang that I see locally (possibly due to different hardware), I can confirm that our rendering is not-entirely-responsive -- sometimes there are blank patches if I drag my scrollbar up and down.

I switched to Chrome and tried and in fact do find it hangs with the extra two steps above. This indicates Github changed something recently that causes this -- I'll probably file an issue with them too.

Question for you, just to clarify: does Chrome hang for roughly the same duration as Firefox? (You can capture a profile of the behavior at Chrome by following instructions at https://developer.chrome.com/docs/devtools/evaluate-performance/reference/ , to get a timeline etc., so you can make sure you're looking objectively. Also If you'd like to share a Chrome profile, you can use their download button (the downarrow icon a few buttons over from their "record" button) to export the profile as a JSON file, and then you can upload that file at https://profiler.firefox.com/ to get a shareable link.)

I think I probably didn't spot it in chrome in my initial test because the page was still rendered (though "not responsive"). In firefox the page rendering freezes and is unresponsive. Hopefully it is useful in some way to the firefox team!

(For what it's worth: I just reproduced an unrendered blank area in Chrome (when scrolling up and down, during the hang); though I agree, it does seem a little easier to trigger that behavior in Firefox.)

Comment 9

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

The severity field is not set for this bug.
:emilio, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

It doesn't seem this is a bug on our end, most likely, though there are some improvements we could make here, will file dependent bugs.