1717597 - Twitter feeds paint very slowly

Status: UNCONFIRMED

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

Description

[TMart]

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

Steps to reproduce:

Access twitter.com and start scrolling in the feed.

Actual results:

The more content is loaded in the feed, the slower the paints get. It takes up to seconds until the content is shown on screen.

This happens both on a Pixel 4a 5G with a SD 765 and another smartphone with a SD 845. This doesn't happen with Chromium based browsers.

To me it doesn't look like an issue with CPU/GPU or network, but the rendering just seems to be very slow. You can see this as already loaded content also disappears for seconds, when I scroll to the top again.

Please see this video, which demonstrates the issue: https://1drv.ms/v/s!ArY6nA0dfc6ug6JknKUneAc62Ux7QQ?e=vmdiYN

Comment 1

[Emily Toop (:fluffyemily)]

Kevin will drop in a profile.

Comment 2

[Emily Toop (:fluffyemily)]

:TMart do you have a profile you can share with us? You can use the Firefox profiler at https://profiler.firefox.com/. There is links to the usage documentation from that page, including information about how to use it on mobile. https://profiler.firefox.com/docs/#/./guide-remote-profiling

Comment 3

[TMart]

Here is the link to the profile, I hope it is helpfull: https://share.firefox.dev/3xQP24o

Comment 4

[Harry Twyford]

Attachment: Bug 1717597 - Convert test_special_search.js. r?adw!

Apologies in advance for this review. It's the test I've had to rewrite the most. This is because the unifiedcomplete tests did not care about sorting, and urlbar tests do. Since this test does some complicated stuff with frecency, many of the expected matches had to be reordered in the test. The old test just listed all the uris in descending order in matches, paying no mind to frecency. As I've been doing with other tests, I reversed the order which with they are added to history/bookmarks, to reduce the number of changes required in the sets of expected matches.
That yielded this order, in descending order of frecency:
uri11
uri1
uri4
uri6
uri5
uri7
uri8
uri9
uri10
uri12
uri2
uri3

Comment 5

[Kevin Brosnan [Ex-Mozilla]]

Something got cross wired here. This is not a search bug.

Comment 6

[Harry Twyford]

Thanks! It was a typo in the bug number.

Comment 7

[Phabricator Automation]

Comment on attachment 9229781 [details]
Bug 1717597 - Convert test_special_search.js. r?adw!

Revision D119113 was moved to bug 1717507. Setting attachment 9229781 [details] to obsolete.

Comment 8

[Emily Toop (:fluffyemily)]

Agi to look at the profile and send to the correct Gecko team

Comment 9

[[ex-Mozilla] Agi Sferro | :agi]

From the profile in Comment #3 we're spending most of the CPU time in JIT javascript.

Comment 10

[Iain Ireland [:iain]]

The hot JS here mostly appears to be in ReactDOM code. We have a metabug open to track improvements to ReactDOM performance.