1622455 - Firefox tab freezes when a huge log is displayed on Github Actions

Status: UNCONFIRMED

(Core :: Performance: Responsiveness, defect, P2)

Description

[mathieu.tarral]

Attachment: firefox_tab_freeze.webm

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

Steps to reproduce:

I went to a job I configured on Github Actions, involving download a qcow image via wget, which puts a lot of log lines to display.

Actual results:

The tab just freezes (even though the progress indicators in Github Actions are still running).
I can't click on refresh, the interface won't respond.
I can't click enter in the address bar, it won't respond either.

The only solution is to close the tab and open the link again.

Expected results:

The tab and the UI should not have been frozen.

see the video I attached for the demo.
100% reproducible.

Comment 1

[Simona Badau, Desktop QA]

Mathieu, could you please try to reproduce the issue on the latest Nightly? You can download it from https://nightly.mozilla.org/

If the issue is reproducible also on the latest Nightly, could you please try to capture a performance profile using the Cleopatra add-on? You can get more info on how to install and use the Cleopatra add-on (that helps you get the performance profile) by going to:

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler
https://perf-html.io/
Please also note that this add-on works only on FF Nightly, so that means you need to be able to reproduce the issue on Nightly first.

Mike, Eric, could you please take a look over?

Comment 2

[Eric Rahm [:erahm]]

There's nothing actionable on my side at this point.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Clearing needinfo while we wait to get that profile from the reporter.

Comment 4

[mathieu.tarral]

Hi and thank you for the quick feedback.

I downloaded the latest nightly, which already included the profiler. (76.0a1 (2020-03-22) (64 bits))

I ran the test on Github Actions while downloading a Windows 7 image via wget (3,23 Go)

What I noticed was that there was no complete freeze of the interface, as I was expecting.
However, when I tried to expand or collapse the current task which was downloading the file, my action would have no effect whatsoever.

Only at the end of the Github Actions workflow my action were taken into account, and all the tasks would receive the expand/collapse clicks at the same time.

This does seem like a performance issue, so I recorded a profile, that you can find here:
https://perfht.ml/2WzsWnj

I also created a Github repo dedicated to this issue:
https://github.com/Wenzel/test_bug_actions

You can fork this repo and make PRs, the Github Actions will trigger automatically, and experiment the issue by yourself.

Thank you !

Comment 5

[mathieu.tarral]

Additional note: I created a separate profile for nightly:

• mkdir ~/nightly_profile
• ./firefox --profile ~/nightly_profile

Comment 6

[Simona Badau, Desktop QA]

Mike, Eric, could you please take a look over?

Comment 7

[Eric Rahm [:erahm]]

(In reply to Simona Badau from comment #6)

Mike, Eric, could you please take a look over?

Happy to help triage memory reports (when a user pastes output from about:memory or attaches a memory report), in this case we're looking at a perf profile (via perf.html) so I'm not the right person to ask.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

This looks to me like the important part of the profile: https://perfht.ml/2x5dsgN

It looks like a bunch of expensive Promises / callbacks / MutationCallbacks are executing in a row, and they're running JS and doing DOM operations.

Going to move this into Core::Performance and tag with [qf] so that hopefully some of our JS or DOM folks can find a more appropriate component.