Hello, I’m seeing a repeatable multi-second delay when selecting words in the reader in both LibreWolf and plain Firefox on Linux (desktop). I cannot reproduce the issue in Chrome.
Basic reproducer is: Open a text with a long YouTube video (e.g. an hour podcast video) attached to it, in the normal reader in Firefox, select a few words with the mouse to translate, wait for translation.
Basically there seems to be something blocking the UI between when I release the mouse button (after selecting some text) and before the call to /api/translate happens. The call to /api/translate takes ~500ms on average for me, but the time in between releasing the mouse button and when that call actually fires is often several seconds for me (which naturally can break immersion when translating while watching a video).
I recorded a profile:
- mouseup occurred at approximately 2.972 s.
/api/translatewas requested at approximately 5.648 s.- That is ~2.6 s of client-side work before the request.
- The profiler showed ~3.1 s of input latency for the associated click event, consistent with the main thread being blocked.
- The server began responding after 594 ms from the request, so most of the perceived delay occurred before networking began.
After mouseup, the thread seemed busy in src/app.js (particularly in function Xr() if you have a source map, the bust id is b3ddd78ef88802783b6d954fc530c87d0dd43968).
The same multi-second main-thread stall occurs when clicking the translated phrase again to unsave it. The problem also seems strongly correlated with texts that have a long YouTube video attached; shorter videos/texts are much more responsive.
Happy to provide any extra info, or I can try to get you the profiler output (my initial recording also has metadata for other unrelated tabs, so I didn’t include it here; I could make a fresh one in a new browser profile and send it, if it is useful).
Rick