2045569 - Scrolling through Reddit on Android has laggy scrolling

Status: NEW

(Firefox for Android :: Performance, defect)

Description

[Jonathan Almeida [:jonalmeida]]

Steps to reproduce

1. Scroll through reddit.com.

Expected behaviour

• Smooth scrolling.

Actual behaviour

• Laggy scrolling.

Device information

• Firefox version: 153.0.a1
• Android device model: Pixel 5
• Android OS version: Android 14

Any additional information?

• Potential duplicate: bug 2019852
• Profile with Graphics preset: https://profiler.firefox.com/public/j0s4cdpngjdsz9axx0rbq3z3fxw82pesz4x7wn8
• Observed by a few folks including some redditors.

Comment 1

[Jonathan Almeida [:jonalmeida]]

Using the profiler-analysis Claude skill with the profile link above, this is a possible cause:

Profile summary

Profile: Firefox Nightly 153 on Android 14, 25.8s capture. The selected thread t-3 is the Web Content GeckoMain for reddit.com/r/firefox/ (PID 9173). It accumulated 4.48s of CPU (~17% utilization), with the GPU Renderer thread burning the most CPU overall (6.77s on t-9).

Three findings worth attention

1. Accessibility is forcing a full viewport display list build every refresh tick

The single most surprising pattern in the profile. NotificationController::WillRefresh (the a11y notification dispatcher) keeps calling into nsLayoutUtils::GetFramesForArea → ViewportFrame::BuildDisplayList:

ViewportFrame::BuildDisplayList         total: 1946 (35.7%)
  ← nsLayoutUtils::GetFramesForArea     total: 1037 (19.0%)
  ←   NotificationController::WillRefresh total: 1036 (19.0%)
  ←     RefreshDriver tick

So roughly one in every five samples on this thread is the a11y controller forcing a fresh display-list build to do hit-testing/frame lookup. The leaf cost shows up in a long tail of unsymbolicated libxul.so!0x6fdf7d* addresses (display item construction code). This looks like a real Gecko bug worth investigating — either the a11y NotificationController is calling GetFramesForArea more often than needed, or it should be using a cheaper frame-lookup path that doesn't trigger a viewport display list rebuild. Worth checking whether a TalkBack/screen-reader session was active when the profile was captured.

2. An Android logcat hot path running inside display-list building

3.6% self time sits on libc.so!0x731a96f6d8 reached via:

libmozglue!0x6ff3f204f4 → liblog (×3 frames) → libbase (×2) → libartbase → libbase → liblog → libc

The 7.3% self time on [vdso]!0x7325a56440 (almost certainly clock_gettime) shares the same parents. This is a __android_log_print-style call invoked from libmozglue (likely a MOZ_LOG/NS_WARN_IF/assertion path) being hit per display item during ViewportFrame::BuildDisplayList. ~11% of the thread's CPU disappearing into logcat + clock_gettime from layout is a real cost on Android Nightly builds — worth checking which log channel is enabled and whether it should be.

3. Reddit's virtualizeTopElements is the dominant JS contributor

During the longest jank (m-13, 310ms at t=11.58s), 26.7% of active CPU was a setTimeout from redditstatic.com:

TimeoutExecutor Runnable → promise → AsyncFunctionNext
  → _virtualizeTop → virtualizeTopElements → forEach
    → Node.replaceChild (24% of jank)
       ├─ custom-element disconnectedCallback (7.8%)
       └─ nsCSSFrameConstructor::ContentWillBeRemoved (6.1%)

A single virtualization tick is doing many replaceChild calls and each one fires custom-element lifecycle callbacks and frame teardown. The other 73% of that jank window is the style/layout cascade that Reddit's mutation triggered. This one isn't Firefox's fault, but it's the proximate cause of the worst frame-time stalls.

Other notes

- 10 jank markers total (50–310 ms), 3 long-task markers ≥50 ms — all clustered around Reddit's virtualization passes.
- The libxul addresses look unsymbolicated because this is a local Nightly APK build; the Mozilla symbol server doesn't have symbols for that exact 0482C0DB... build of libxul.so. If you want to drill into the display-list code, pointing profiler-cli load --symbol-server at a local symbol server with matching symbols would resolve the 0x6fdf7d* addresses.
- The GPU Renderer thread (t-9, 6.77s CPU) is the highest single-thread cost; if you also want me to look there, say the word.

Comment 2

[Sree]

Hello I have captured the profile as you have asked me. The link https://profiler.firefox.com/public/rpcr3xcj92dpjg6z7xfmzxsnax6je2n0wh6dc1g
Device ONEPLUS 12R
FIREFOX BETA 152.0b8

Comment 3

[Jonathan Almeida [:jonalmeida]]

Kaya, could you take a quick peek at this? I think this should go to Layout, but maybe you have a better sense on the causes for the jank.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

(In reply to Jonathan Almeida [:jonalmeida] from comment #1)

Using the profiler-analysis Claude skill with the profile link above, this is a possible cause:

This analysis is bad.

It looks like there's some really bad stuff happening on the Renderer thread in the first profile. Unfortunately, the symbols in the profile are missing. The second profile doesn't load for me at all.

Comment 5

[Jonathan Almeida [:jonalmeida]]

Marked comment 2 as obsolete.

Comment 6

[Sree]

Hello Im sharing the log downloaded with Firefox nightly. The scrolling has improved a lot in the newest version of firefox. There are still few stutters when scrolling through pages having a lot of images and video. .
https://profiler.firefox.com/public/w4vxsbfgzvjk22b4b3pssx9at5qfwwnqm6szdr8

Comment 7

[Wayne Mery (:wsmwk)]

Last profile has symbols.