Skip to content

UI freezes when clipboard is empty after screen lock

summary

when i clear my clipboard and then lock+unlock my screen, the Tor Browser UI freezes for a moment whenever i interact with it. this fixes itself when i copy anything to the clipboard and breaks again if i repeat the process.

i have tested that this works in Tor Browser alpha (14.0a9) and stable (13.5.4), both using the “standard” security level.

i know it’s a weird corner case, but it’s very reproducible.

steps to reproduce

  1. launch Tor Browser.
  2. clear the clipboard (by using the “clipboard contents” tray icon or by not copying anything after logging in).
  3. lock and unlock the screen.
  4. interact with the browser UI in any way (open/close a tab, type in the search/URL bar, etc).

what is the current bug behavior?

the interface freezes for exact multiples of 1 second (consistently), then processes the input.

what is the expected behavior?

the interface does not freeze and processes input instantly.

environment

i’m using Debian 12 stable (x86-64) with the KDE Plasma Wayland session, version 5.27.5.

i installed Tor Browser alpha and stable by downloading the release tarballs from the Tor website.

relevant logs and screenshots

i’ve attached an anonymized performance profile from the Firefox profiler running on Tor Browser alpha 14.0a9.

the key takeaway (from my layman’s point of view) is that the freezes (or “jank” as the profiler calls them) always happen within calls to nsIClipboard.getData, which contain two calls to __GI___poll which take exactly 1 second each. in total, each freeze lasts exactly 2 seconds.

i remember the freezes in Tor Browser stable 13.5 and 13.0 lasting exactly 5 seconds each, though i haven’t tested them in a while.