Typing into Quick Reblog's Tag Field is Sometimes Laggy

[Avakining]

Platform

macOS 15.3.1

Browser

Firefox 135.0.1

Addon version

v1.0.6

Details

Sometimes, especially when a Tumblr tab has been open for a while (or multiple pages have been looked through), typing text into Quick Reblog's tags field is laggy. There is substantial, noticeable delay (sometimes about a second and a half) between when I press the key on my keyboard and when it appears on screen. Then, several characters appear in very quick succession.

It's hard to reproduce, but has happened several times in the last few months. This doesn't happen on other sites or in other text fields on Tumblr.

CPU and memory usage on my machine look normal.

If I can manage to make a screen recording of the issue (or, if there is somewhere I can find logs) to help diagnose the issue, I will attach them here

[marcustyphoon]

When this happens, try moving the mouse onto and off of a text block and see if the cursor changing between normal and... whatever the text selection one is called... is delayed. That's my standard test for if something is causing the entire tab to render slowly. That would be my first guess, since I don't remember us doing anything that could plausibly require a lot of computation when you type in that box, but I'll double check.

[stale[bot]]

This issue is unconfirmed, and has been labelled as stale due to inactivity. It will be closed automatically if no further activity occurs.

A project maintainer can mark an issue as confirmed by adding the help wanted label, the wontfix label, or an assignee.

[Avakining]

When this happens, try moving the mouse onto and off of a text block and see if the cursor changing between normal and... whatever the text selection one is called... is delayed.

It just occurred for the first time since I made this issue.

The CPU usage of the Tumblr tab spikes to 100% when typing in the tags box (according to about:processes). It goes back to <1% when I stop typing. The mouse cursor thing happens when I'm typing.

It seems to be reproducible fairly consistently when one tag is fairly long (the one I was trying was 58 characters, and it seems to get worse when more super long tags are added

The screen recordings below show (separate) times typing. I was just running my fingers across the keyboard as fast as I could.

https://github.com/user-attachments/assets/7acd64e7-8100-47b3-a5e7-f5ff0b191a89

https://github.com/user-attachments/assets/bfc2deb7-f807-4ad1-84a6-a44b6933ad9a

[marcustyphoon]

Hm. Definitely can't get it to happen myself, so I'm basically just guessing. There are a few lines of code that we run each time that box takes input, two of which are definitely not the cause and one of which... maybe possibly could be, if Firefox is really bad at displaying the "Tag is longer than 140 characters!" message we're using, or something? I guess I can ensure that we only update that box when necessary.

Is this on a page with, like, multiple hundreds of posts loaded on it, out of curiosity? Is this on a regular dashboard/someone's blog/the drafts or queue page/tumblr patio?

[Avakining]

This is on the (paginated) dashboard, so only a handful of posts at a time.

[marcustyphoon]

You know, I think I've actually identified that Tumblr itself is running a bunch of code when one types into a box, and it's probably an intricate bug in Tumblr's setup that makes this a) potentially laggy and b) triggered on non-tumblr text boxes. I'll send in a report about my findings and see what happens.

[Avakining]

Anecdotally, it seems like this issue could be related to using the iCloud Passwords add-on. It seems like the extension sometimes (but rarely and seemingly randomly) decides to check to see if a text entry box is for passwords every time a character is entered for some reason.

My guess is, that add-on, when combined with whatever Tumblr is doing, cause this issue.

I've thus submitted a Feedback (FB17502283) to Apple and linked to this issue.

[github-actions[bot]]

This issue is unconfirmed, and has been labelled as stale due to inactivity. It will be closed automatically if no further activity occurs. A project maintainer can mark an issue as confirmed by adding the help wanted label, the wontfix label, or an assignee.