#410 Login page shows no text for about 20 s on a fresh profile (WebKitGTK)

[Anonymous]

Originally created by: kristofferR

Problem

On a fresh, logged-out profile, Facebook's login page often shows no text and no images for about 20 seconds on Linux. The form's boxes and buttons are drawn, but the heading, placeholders, button labels and the cookie dialog's card images stay blank until about 19.5 s after the page starts loading, then everything appears at once.

Evidence

Measured on Omarchy (Hyprland, Wayland), webkit2gtk-4.1 2.54.2-1, with an isolated profile per run:

• It happens in roughly 2 of 3 fresh runs, in Chatpane and in plain WebKitGTK MiniBrowser --private https://www.facebook.com/login.php alike. MiniBrowser stalled in 2 of 3 runs with the same blank form and missing card images.
• Chatpane stalls the same with every injected page feature disabled, and on the installed main build, so it isn't caused by Chatpane's page code. Plain MiniBrowser rules out Chatpane's native side too.
• All of the page's resources load within about 1.7 s (CSS at 0.03 s, the form's woff2 font at 0.7 s, images at 0.6 s). Nothing is in flight during the stall, and ss shows no pending connections.
• The page's own timers and animation frames stop: a 1 s setTimeout chain logged at 0.6 s and 1.5 s, then next at 20.5 s. requestAnimationFrame ran 4 times by 0.6 s and 69 times by 20.5 s.
• The web process uses about 1 s of CPU in those 20 s, and its main thread sits in __futex_wait (ptrace is blocked, so no stack). That points at a blocking wait, likely a synchronous IPC reply, rather than work.
• Facebook resumes on its own at about 19.5 s: four JS preloads and XHRs start together, then the text paints. Resizing the window and moving the pointer don't end it early. Disabling the DMA-BUF renderer doesn't change it.

Next steps

• Get a web process stack during the stall (needs ptrace permission or a WebKitGTK debug build) to see which synchronous call it waits on.
• Check whether a newer WebKitGTK fixes it, then report upstream with a MiniBrowser reproduction.

[#411] covers the blank page with a loader until the text has rendered; the stall itself remains.

[Anonymous]

Originally posted by: kristofferR

[!NOTE]
🤖 Claude Opus 5.5 responding on behalf of Kristoffer

Update: [#411] is on main and ships in the next release. While the login page hasn't rendered its text, Carrier now shows a loader: the paper plane, "Loading Messenger…", and a slim sliding bar. It disappears as soon as the form's text has actually rendered, or fades out after 15 s at most. Only transform and opacity are animated, it stops completely once hidden, and it stays static under reduced motion. The same PR keeps Facebook's cookie dialog and its "Learn more" pages in view.

That only covers the symptom. The ~20 s WebKitGTK stall itself is still there, and this issue stays open for it. The next steps are unchanged: capture a web-process stack during the stall, test a newer WebKitGTK, and report upstream with the MiniBrowser reproduction.