[GH-ISSUE #40] Characters getting swallowed while typing #30

New issue

Closed

opened 2026-10-30 21:17:21 +00:00 by bsakaguchi · 38 comments

bsakaguchi commented 2026-10-30 21:17:21 +00:00

Owner

Copy link

Originally created by @byzod on GitHub (Oct 25, 2022).
Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/40

When showAllResults is true (as I said in https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/34#issue-1420740828, it's basically necessary for chinese users), characters maybe swallowed when typing, even with small resultStepLength (50 in my case)

Demo: when I try to type guro

A possible and popular way to solve this is to delayed the keypress event handler until user stop typing, or handle it asynchronously

For example generate the dropdown list keypressHandlerDelay ms later after user stops typing, the default value of the delay could be 300 ms or something and can be changed in config.json

Originally created by @byzod on GitHub (Oct 25, 2022). Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/40 When `showAllResults` is `true` (as I said in https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/34#issue-1420740828, it's basically necessary for chinese users), characters maybe swallowed when typing, even with small `resultStepLength` (`50` in my case) Demo: when I try to type `guro`  A possible and popular way to solve this is to [delayed the keypress event handler until user stop typing](https://www.includehelp.com/jquery/how-to-delay-the-keyup-handler-until-the-user-stops-typing-using-jquery.aspx), or handle it [asynchronously](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await) For example generate the dropdown list `keypressHandlerDelay` ms later after user stops typing, the default value of the delay could be `300` ms or something and can be changed in `config.json`

bsakaguchi 2026-10-30 21:17:21 +00:00

• closed this issue
• added the
  bug
  help wanted
  labels

bsakaguchi commented 2026-10-30 21:17:23 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 25, 2022):

Swallowing characters has never happened to me before, even when resultStepLength is a much higher value like 50000.
Yes, the browser will lag for potentially seconds in that case - but the typed characters are still queued and will still be input after it catches up:

https://user-images.githubusercontent.com/34448969/197771776-f1f8b06a-99ed-40f7-af0b-920ccc11a9de.mp4

In this clip I typed them all at the beginning, and it will obviously lag since it tries to display 50000 entries at first, but still adds the rest of the characters afterwards.

Also regarding your delay suggestion, in fact this is already in place: the key change listener uses a debounce function which prevents re-triggering the function until the timer has passed. Default value is 100 ms.
Since I can't seem to reproduce the character swallowing, please try out the following:

This should be line 675 of tagAutocomplete.js, try editing the 100 to a higher value, like 300, 500 or even 1000.

area.addEventListener('input', debounce(() => autocomplete(area, area.value), 100));

If it helps your situation to have a higher timer, I can add that to the config.

A proper asynchronous implementation would be the only proper solution to the core problem, but with smaller step sizes I never felt the need, at least on my system. What are your specs?

<!-- gh-comment-id:1290464067 --> @DominikDoom commented on GitHub (Oct 25, 2022): Swallowing characters has never happened to me before, even when resultStepLength is a much higher value like 50000. Yes, the browser will lag for potentially seconds in that case - but the typed characters are still queued and will still be input after it catches up: https://user-images.githubusercontent.com/34448969/197771776-f1f8b06a-99ed-40f7-af0b-920ccc11a9de.mp4 In this clip I typed them all at the beginning, and it will obviously lag since it tries to display 50000 entries at first, but still adds the rest of the characters afterwards. Also regarding your delay suggestion, in fact this is already in place: the key change listener uses a debounce function which prevents re-triggering the function until the timer has passed. Default value is 100 ms. Since I can't seem to reproduce the character swallowing, please try out the following: This should be line 675 of tagAutocomplete.js, try editing the 100 to a higher value, like 300, 500 or even 1000. ```js area.addEventListener('input', debounce(() => autocomplete(area, area.value), 100)); ``` If it helps your situation to have a higher timer, I can add that to the config. A proper asynchronous implementation would be the only proper solution to the core problem, but with smaller step sizes I never felt the need, at least on my system. What are your specs?

bsakaguchi commented 2026-10-30 21:17:24 +00:00

Author

Owner

Copy link

@byzod commented on GitHub (Oct 25, 2022):

A proper asynchronous implementation would be the only proper solution to the core problem, but with smaller step sizes I never felt the need, at least on my system. What are your specs?

Thanks, bad news: increase 100 to 1000 not working

Good news: I found out a different behavior

I wrote a GM script and ahk script found out that it's not your script but both firefox+your script swallowed the keypress

The keypress are NOT swallowed on Microsoft Edge and Chrome, only on Firefox and I can reproduce it on a fresh new profile so it's not a extension related bug, can you investigate it?

p.s. I never had similar problem on firefox with other scripts or web applications so I think my firefox is not broken, maybe

Firefox I use: https://ftp.mozilla.org/pub/devedition/candidates/107.0b4-candidates/build1/win64/zh-CN/firefox-107.0b4.zip

Webui config and test script (if it helps):
config.zip

Spec and webui command args

OS Name : Windows 10 Home China (64-bit) 
OS Version : 21H2
OS Build : 19044.2130
Current ANSI codepage : 936

COMMANDLINE_ARGS=--xformers --no-half-vae --deepdanbooru

<!-- gh-comment-id:1290543267 --> @byzod commented on GitHub (Oct 25, 2022): > A proper asynchronous implementation would be the only proper solution to the core problem, but with smaller step sizes I never felt the need, at least on my system. What are your specs? Thanks, bad news: increase `100` to `1000` not working Good news: I found out a different behavior I wrote a GM script and ahk script found out that it's not your script but both firefox+your script swallowed the keypress  The keypress are NOT swallowed on Microsoft Edge and Chrome, only on Firefox and I can reproduce it on a fresh new profile so it's not a extension related bug, can you investigate it? p.s. I never had similar problem on firefox with other scripts or web applications so I think my firefox is not broken, maybe Firefox I use: https://ftp.mozilla.org/pub/devedition/candidates/107.0b4-candidates/build1/win64/zh-CN/firefox-107.0b4.zip Webui config and test script (if it helps): [config.zip](https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/files/9860584/config.zip) Spec and webui command args ``` OS Name : Windows 10 Home China (64-bit) OS Version : 21H2 OS Build : 19044.2130 Current ANSI codepage : 936 ``` ``` COMMANDLINE_ARGS=--xformers --no-half-vae --deepdanbooru ```

bsakaguchi commented 2026-10-30 21:17:24 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 25, 2022):

Alright, thanks for the details. I'll try it on Firefox and see if I can find the cause.

<!-- gh-comment-id:1290550283 --> @DominikDoom commented on GitHub (Oct 25, 2022): Alright, thanks for the details. I'll try it on Firefox and see if I can find the cause.

bsakaguchi commented 2026-10-30 21:17:24 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 25, 2022):

Very strange, even using the Firefox version and the test scripts you gave me, I can't reproduce the swallowing bug. It behaves pretty much the same as my Chrome instance in that regard. I tried various settings but none made a difference for it.

Does it also happen at smaller step sizes? 50 items shouldn't cause much lag.

<!-- gh-comment-id:1290630436 --> @DominikDoom commented on GitHub (Oct 25, 2022): Very strange, even using the Firefox version and the test scripts you gave me, I can't reproduce the swallowing bug. It behaves pretty much the same as my Chrome instance in that regard. I tried various settings but none made a difference for it. Does it also happen at smaller step sizes? 50 items shouldn't cause much lag.

bsakaguchi commented 2026-10-30 21:17:25 +00:00

Author

Owner

Copy link

@byzod commented on GitHub (Oct 25, 2022):

Very strange, even using the Firefox version and the test scripts you gave me, I can't reproduce the swallowing bug. It behaves pretty much the same as my Chrome instance in that regard. I tried various settings but none made a difference for it.

Does it also happen at smaller step sizes? 50 items shouldn't cause much lag.

It happens even with 20 step size ;_;

With 20 steps it's not lag that much, but I still lost some input

I can't think of what could cause this problem :/

<!-- gh-comment-id:1290638933 --> @byzod commented on GitHub (Oct 25, 2022): > Very strange, even using the Firefox version and the test scripts you gave me, I can't reproduce the swallowing bug. It behaves pretty much the same as my Chrome instance in that regard. I tried various settings but none made a difference for it. > > Does it also happen at smaller step sizes? 50 items shouldn't cause much lag. It happens even with 20 step size ;_; With 20 steps it's not lag that much, but I still lost some input I can't think of what could cause this problem :/

bsakaguchi commented 2026-10-30 21:17:25 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 25, 2022):

What CPU & RAM do you have, if that isn't too private? At 20 I am really surprised to hear you still have noticeable lag.

<!-- gh-comment-id:1290647794 --> @DominikDoom commented on GitHub (Oct 25, 2022): What CPU & RAM do you have, if that isn't too private? At 20 I am really surprised to hear you still have noticeable lag.

bsakaguchi commented 2026-10-30 21:17:25 +00:00

Author

Owner

Copy link

@byzod commented on GitHub (Oct 25, 2022):

Also regarding your delay suggestion, in fact this is already in place: the key change listener uses a debounce function which prevents re-triggering the function until the timer has passed. Default value is 100 ms. Since I can't seem to reproduce the character swallowing, please try out the following:

This should be line 675 of tagAutocomplete.js, try editing the 100 to a higher value, like 300, 500 or even 1000.

area.addEventListener('input', debounce(() => autocomplete(area, area.value), 100));

I set this value to 2000 and it won't swallow my input before the dropdown list shown, thanks!

I will use this as a workaround for now

What CPU & RAM do you have, if that isn't too private? At 20 I am really surprised to hear you still have noticeable lag.

i5-11400F & 16GB RAM & RTX 3060Ti

It's not a super pc but I think it can handle few js script...

To be clear that when using low step size, it's not lag, just input got swallowed, the dropdown list generated almost instantly

Demo: me trying to type goggles with step size 100, the result shows up quick but words swallowed

<!-- gh-comment-id:1290668583 --> @byzod commented on GitHub (Oct 25, 2022): > Also regarding your delay suggestion, in fact this is already in place: the key change listener uses a debounce function which prevents re-triggering the function until the timer has passed. Default value is 100 ms. Since I can't seem to reproduce the character swallowing, please try out the following: > > This should be line 675 of tagAutocomplete.js, try editing the 100 to a higher value, like 300, 500 or even 1000. > > ```js > area.addEventListener('input', debounce(() => autocomplete(area, area.value), 100)); > ``` I set this value to 2000 and it won't swallow my input before the dropdown list shown, thanks! I will use this as a workaround for now > What CPU & RAM do you have, if that isn't too private? At 20 I am really surprised to hear you still have noticeable lag. i5-11400F & 16GB RAM & RTX 3060Ti It's not a super pc but I think it can handle few js script... To be clear that when using low step size, it's not lag, just input got swallowed, the dropdown list generated almost instantly Demo: me trying to type `goggles` with step size `100`, the result shows up quick but words swallowed 

bsakaguchi commented 2026-10-30 21:17:26 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 25, 2022):

i5-11400F & 16GB RAM & RTX 3060Ti

Yeah with that it should definitely be no problem.

If the swallowing isn't related to lag it's even stranger. The script shouldn't prevent key events at any time, and only blocks the default for the navigation keys like Arrow Up/Down etc.
If the workaround with the high debounce works in the meantime that's good, I'll get back to you if I find anything else.

<!-- gh-comment-id:1290683252 --> @DominikDoom commented on GitHub (Oct 25, 2022): > i5-11400F & 16GB RAM & RTX 3060Ti Yeah with that it should definitely be no problem. If the swallowing isn't related to lag it's even stranger. The script shouldn't prevent key events at any time, and only blocks the default for the navigation keys like Arrow Up/Down etc. If the workaround with the high debounce works in the meantime that's good, I'll get back to you if I find anything else.

bsakaguchi commented 2026-10-30 21:17:26 +00:00

Author

Owner

Copy link

@Evil-Dragon commented on GitHub (Oct 26, 2022):

I opened a bug report that is the same issue to this, when typing something into the boxes it would miss letters and spaces. I thought i'd broken my keyboard. Didn't think at the time that this bug report was related but it is. I was using the default "resultStepLength": 500, but never changed it, i suspect it woud happen no matter what step length I choose.

EDIT: I'm using English so i doubt this is specifically related to Chinese.

<!-- gh-comment-id:1291775891 --> @Evil-Dragon commented on GitHub (Oct 26, 2022): I opened a bug report that is the same issue to this, when typing something into the boxes it would miss letters and spaces. I thought i'd broken my keyboard. Didn't think at the time that this bug report was related but it is. I was using the default "resultStepLength": 500, but never changed it, i suspect it woud happen no matter what step length I choose. EDIT: I'm using English so i doubt this is specifically related to Chinese.

bsakaguchi commented 2026-10-30 21:17:26 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 26, 2022):

@Evil-Dragon Can you try launching your Firefox in safe mode (Hold shift wile starting it)?
I'm still looking for what could cause this since it works normally on my Firefox with Win10.

<!-- gh-comment-id:1291783519 --> @DominikDoom commented on GitHub (Oct 26, 2022): @Evil-Dragon Can you try launching your Firefox in safe mode (Hold shift wile starting it)? I'm still looking for what could cause this since it works normally on my Firefox with Win10.

bsakaguchi commented 2026-10-30 21:17:26 +00:00

Author

Owner

Copy link

@Evil-Dragon commented on GitHub (Oct 26, 2022):

This is in Firefox Safe Mode. I was typing 1girl, sitting at a park bench.

I really wish I could say that my typing is that bad but it isn't, lol

EDIT: Gonna try some of your script roll backs and see when it started happening.

<!-- gh-comment-id:1291789749 --> @Evil-Dragon commented on GitHub (Oct 26, 2022):  This is in Firefox Safe Mode. I was typing 1girl, sitting at a park bench. I really wish I could say that my typing is that bad but it isn't, lol EDIT: Gonna try some of your script roll backs and see when it started happening.

bsakaguchi commented 2026-10-30 21:17:26 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 26, 2022):

That confirms it doesn't have anything to do with extensions, settings, etc. which matches what byzod reported.

EDIT: Gonna try some of your script roll backs and see when it started happening.

That would be great, if doesn't occur in prior versions I'll at least have a starting point.

<!-- gh-comment-id:1291797211 --> @DominikDoom commented on GitHub (Oct 26, 2022): That confirms it doesn't have anything to do with extensions, settings, etc. which matches what byzod reported. > EDIT: Gonna try some of your script roll backs and see when it started happening. That would be great, if doesn't occur in prior versions I'll at least have a starting point.

bsakaguchi commented 2026-10-30 21:17:27 +00:00

Author

Owner

Copy link

@Evil-Dragon commented on GitHub (Oct 26, 2022):

Hotfix 1.7.1 was stable for me, no missed characters or spaces when typing. I didn't try 1.7.2 because that was causing some infinite wildcard reloading of 30+ text files and it was killing my Firefox at the time. Obviously 1.7.3 was released to address that issue but it seems it might have caused some additional issues or it started in 1.7.2, not too sure.

<!-- gh-comment-id:1291801471 --> @Evil-Dragon commented on GitHub (Oct 26, 2022): Hotfix 1.7.1 was stable for me, no missed characters or spaces when typing. I didn't try 1.7.2 because that was causing some infinite wildcard reloading of 30+ text files and it was killing my Firefox at the time. Obviously 1.7.3 was released to address that issue but it seems it might have caused some additional issues or it started in 1.7.2, not too sure.

bsakaguchi commented 2026-10-30 21:17:27 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 26, 2022):

Could you try 1.7.2 with wildcards disabled and see if the characters are swallowed there? 1.7.3 didn't change anything regarding normal completion, so I don't think it's that.

<!-- gh-comment-id:1291807318 --> @DominikDoom commented on GitHub (Oct 26, 2022): Could you try 1.7.2 with wildcards disabled and see if the characters are swallowed there? 1.7.3 didn't change anything regarding normal completion, so I don't think it's that.

bsakaguchi commented 2026-10-30 21:17:27 +00:00

Author

Owner

Copy link

@byzod commented on GitHub (Oct 26, 2022):

I tried 1.7.1, still got swallowed, I think we have different issue ;_;

<!-- gh-comment-id:1291847728 --> @byzod commented on GitHub (Oct 26, 2022): I tried 1.7.1, still got swallowed, I think we have different issue ;_;

bsakaguchi commented 2026-10-30 21:17:28 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 26, 2022):

Might also just be a misremembered version then.

Since I can't really do testing without the cause, can you please try to comment out line 475 (in the newest version)?

addResultsToList(textArea, results, tagword, true);

That way the autocomplete function still gets called, but the results aren't added to the div. I want to find out if it's related to the displaying or processing.

<!-- gh-comment-id:1291853489 --> @DominikDoom commented on GitHub (Oct 26, 2022): Might also just be a misremembered version then. Since I can't really do testing without the cause, can you please try to comment out line 475 (in the newest version)? ```js addResultsToList(textArea, results, tagword, true); ``` That way the autocomplete function still gets called, but the results aren't added to the div. I want to find out if it's related to the displaying or processing.

bsakaguchi commented 2026-10-30 21:17:28 +00:00

Author

Owner

Copy link

@Evil-Dragon commented on GitHub (Oct 26, 2022):

1.7.2 seems ok with wildcards disabled. Not getting any swallowed characters.

<!-- gh-comment-id:1291863440 --> @Evil-Dragon commented on GitHub (Oct 26, 2022): 1.7.2 seems ok with wildcards disabled. Not getting any swallowed characters.

bsakaguchi commented 2026-10-30 21:17:28 +00:00

Author

Owner

Copy link

@Evil-Dragon commented on GitHub (Oct 26, 2022):

And now it appears 1.7.3 is working without issue, i'm totally lost. Caching issue? I've been making a habit of disabling cache in F12 between upgrading and testing these latest versions. Perhaps something was getting cached causing the typing dropouts? That said right now I have wildcards and embedding and translation as set as false.

<!-- gh-comment-id:1291870395 --> @Evil-Dragon commented on GitHub (Oct 26, 2022): And now it appears 1.7.3 is working without issue, i'm totally lost. Caching issue? I've been making a habit of disabling cache in F12 between upgrading and testing these latest versions. Perhaps something was getting cached causing the typing dropouts? That said right now I have wildcards and embedding and translation as set as false.

bsakaguchi commented 2026-10-30 21:17:29 +00:00

Author

Owner

Copy link

@byzod commented on GitHub (Oct 26, 2022):

And now it appears 1.7.3 is working without issue, i'm totally lost. Caching issue? I've been making a habit of disabling cache in F12 between upgrading and testing these latest versions. Perhaps something was getting cached causing the typing dropouts? That said right now I have wildcards and embedding and translation as set as false.

Even ctrl+f5 is not enough to reload it correctly, I always close webui and reboot it to make sure no cache is messing with

<!-- gh-comment-id:1291872880 --> @byzod commented on GitHub (Oct 26, 2022): > And now it appears 1.7.3 is working without issue, i'm totally lost. Caching issue? I've been making a habit of disabling cache in F12 between upgrading and testing these latest versions. Perhaps something was getting cached causing the typing dropouts? That said right now I have wildcards and embedding and translation as set as false. Even ctrl+f5 is not enough to reload it correctly, I always close webui and reboot it to make sure no cache is messing with

bsakaguchi commented 2026-10-30 21:17:29 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 26, 2022):

Even ctrl+f5 is not enough to reload it correctly, I always close webui and reboot it to make sure no cache is messing with

Yeah for the script itself you need to restart the webui, but that's due to gradio preprocessing the website. So the new version of the script only gets processed & added to the server at startup, not during normal page reloads.

But either way caching shouldn't cause the missing characters.

<!-- gh-comment-id:1291876995 --> @DominikDoom commented on GitHub (Oct 26, 2022): > Even ctrl+f5 is not enough to reload it correctly, I always close webui and reboot it to make sure no cache is messing with Yeah for the script itself you need to restart the webui, but that's due to gradio preprocessing the website. So the new version of the script only gets processed & added to the server at startup, not during normal page reloads. But either way caching shouldn't cause the missing characters.

bsakaguchi commented 2026-10-30 21:17:29 +00:00

Author

Owner

Copy link

@byzod commented on GitHub (Oct 26, 2022):

Might also just be a misremembered version then.

Since I can't really do testing without the cause, can you please try to comment out line 475 (in the newest version)?

addResultsToList(textArea, results, tagword, true);

That way the autocomplete function still gets called, but the results aren't added to the div. I want to find out if it's related to the displaying or processing.

Finally something different

I change line 475 to two lines

 // addResultsToList(textArea, results, tagword, true);
 console.log("try to add results");

Then in the prompt area, typing feels smooth like hell, not a single character got swallowed and there are many log in console so it's actually working

I suppose this means it's a render issue?

<!-- gh-comment-id:1291887309 --> @byzod commented on GitHub (Oct 26, 2022): > Might also just be a misremembered version then. > > Since I can't really do testing without the cause, can you please try to comment out line 475 (in the newest version)? > > ```js > addResultsToList(textArea, results, tagword, true); > ``` > > That way the autocomplete function still gets called, but the results aren't added to the div. I want to find out if it's related to the displaying or processing. Finally something different I change line 475 to two lines // addResultsToList(textArea, results, tagword, true); console.log("try to add results"); Then in the prompt area, typing feels smooth like hell, not a single character got swallowed and there are many log in console so it's actually working I suppose this means it's a render issue?

bsakaguchi commented 2026-10-30 21:17:30 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 26, 2022):

Seems like it, addResultsToList is where the list elements are created and added to the autocomplete popup div.
So it seems very likely to me that Firefox misses the input because the DOM gets manipulated or a re-render is triggered during that time.

Please try this version of the script:
tagAutocomplete.zip

I tried making the whole autocomplete function async, but don't know if it had an effect.

<!-- gh-comment-id:1291899105 --> @DominikDoom commented on GitHub (Oct 26, 2022): Seems like it, addResultsToList is where the list elements are created and added to the autocomplete popup div. So it seems very likely to me that Firefox misses the input because the DOM gets manipulated or a re-render is triggered during that time. Please try this version of the script: [tagAutocomplete.zip](https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/files/9869021/tagAutocomplete.zip) I tried making the whole autocomplete function async, but don't know if it had an effect.

bsakaguchi commented 2026-10-30 21:17:30 +00:00

Author

Owner

Copy link

@byzod commented on GitHub (Oct 26, 2022):

Seems like it, addResultsToList is where the list elements are created and added to the autocomplete popup div. So it seems very likely to me that Firefox misses the input because the DOM gets manipulated or a re-render is triggered during that time.

Please try this version of the script: tagAutocomplete.zip

I tried making the whole autocomplete function async, but don't know if it had an effect.

The delay 2000 is too long to feel any difference so I change it to current default 100

Still a lot of input got swallowed :/

<!-- gh-comment-id:1291914094 --> @byzod commented on GitHub (Oct 26, 2022): > Seems like it, addResultsToList is where the list elements are created and added to the autocomplete popup div. So it seems very likely to me that Firefox misses the input because the DOM gets manipulated or a re-render is triggered during that time. > > Please try this version of the script: [tagAutocomplete.zip](https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/files/9869021/tagAutocomplete.zip) > > I tried making the whole autocomplete function async, but don't know if it had an effect. The delay `2000` is too long to feel any difference so I change it to current default 100 Still a lot of input got swallowed :/

bsakaguchi commented 2026-10-30 21:17:30 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 26, 2022):

Ah yeah that was left high from testing since you previously said the high delay fixed it for you, sorry.

With 2000 it feels really slow to use though, so I would like to find the real problem.
Might also be related to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1098981
Although that is for machine typing without delay. But changing the results list here might aggravate it enough so that it even happens for user typing.

Just out of interest, what happens if you set the delay to 0?
Does it get worse or stay the same?

<!-- gh-comment-id:1291931884 --> @DominikDoom commented on GitHub (Oct 26, 2022): Ah yeah that was left high from testing since you previously said the high delay fixed it for you, sorry. With 2000 it feels really slow to use though, so I would like to find the real problem. Might also be related to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1098981 Although that is for machine typing without delay. But changing the results list here might aggravate it enough so that it even happens for user typing. Just out of interest, what happens if you set the delay to 0? Does it get worse or stay the same?

bsakaguchi commented 2026-10-30 21:17:31 +00:00

Author

Owner

Copy link

@byzod commented on GitHub (Oct 26, 2022):

Ah yeah that was left high from testing since you previously said the high delay fixed it for you, sorry.

With 2000 it feels really slow to use though, so I would like to find the real problem. Might also be related to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1098981 Although that is for machine typing without delay. But changing the results list here might aggravate it enough so that it even happens for user typing.

Just out of interest, what happens if you set the delay to 0? Does it get worse or stay the same?

I thought I would lag like shit but it actually fix the problem..sort of..?! 🤔

Few characters still got swallowed if I type at hyper speed, but at my normal speed it works at a decent level, it's working for me at this kind of usability

I tested 3 version of line 675, all of them feels almost the same (the synchronous version feels a bit of laggy but not sure if it's just my feelings)

        area.addEventListener('input', debounce(async () => await autocomplete(area, area.value), 0));

        area.addEventListener('input', async ()=>await autocomplete(area, area.value));

        area.addEventListener('input', ()=>autocomplete(area, area.value));

I still don't know what caused the problem but now I got a good acceptable workaround, thank you for all the effort :D

p.s. I tested with the version you provided, didn't tested the released version

<!-- gh-comment-id:1291951611 --> @byzod commented on GitHub (Oct 26, 2022): > Ah yeah that was left high from testing since you previously said the high delay fixed it for you, sorry. > > With 2000 it feels really slow to use though, so I would like to find the real problem. Might also be related to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1098981 Although that is for machine typing without delay. But changing the results list here might aggravate it enough so that it even happens for user typing. > > Just out of interest, what happens if you set the delay to 0? Does it get worse or stay the same? I thought I would lag like shit but it actually fix the problem..sort of..?! 🤔  Few characters still got swallowed if I type at hyper speed, but at my normal speed it works at a decent level, it's `working` for me at this kind of usability I tested 3 version of line 675, all of them feels almost the same (the synchronous version feels a bit of laggy but not sure if it's just my feelings) area.addEventListener('input', debounce(async () => await autocomplete(area, area.value), 0)); area.addEventListener('input', async ()=>await autocomplete(area, area.value)); area.addEventListener('input', ()=>autocomplete(area, area.value)); I still don't know what caused the problem but now I got a good acceptable workaround, thank you for all the effort :D p.s. I tested with the[ version you provided](https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/40#issuecomment-1291899105), didn't tested the released version

bsakaguchi commented 2026-10-30 21:17:31 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 26, 2022):

p.s. I tested with the version you provided, didn't tested the released version

That shouldn't make much of a difference, in the custom version I only added the async/await keywords.
So if no delay helped, it should have the same effect with the live version. But if you want, try it with the live version too to make sure.

I'll add the debounce delay as a config option so that it doesn't get overwritten in updates.

<!-- gh-comment-id:1291966000 --> @DominikDoom commented on GitHub (Oct 26, 2022): > p.s. I tested with the version you provided, didn't tested the released version That shouldn't make much of a difference, in the custom version I only added the async/await keywords. So if no delay helped, it should have the same effect with the live version. But if you want, try it with the live version too to make sure. I'll add the debounce delay as a config option so that it doesn't get overwritten in updates.

bsakaguchi commented 2026-10-30 21:17:31 +00:00

Author

Owner

Copy link

@byzod commented on GitHub (Oct 26, 2022):

40d53d89d1 working confirmed, by setting the debounce delay to 0
github.com/DominikDoom/a1111-sd-webui-tagcomplete@40d53d89d1/javascript/tagAutocomplete.js (L675)

<!-- gh-comment-id:1291973279 --> @byzod commented on GitHub (Oct 26, 2022): 40d53d89d16c6fd6e4e05d9ad8f9a46ac27c1352 working confirmed, by setting the debounce delay to 0 https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/blob/40d53d89d16c6fd6e4e05d9ad8f9a46ac27c1352/javascript/tagAutocomplete.js#L675

bsakaguchi commented 2026-10-30 21:17:31 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 26, 2022):

I've added the config option, default is still 100, so you will have to edit the config and set it to 0 there.

I'll keep this issue open since it's not solving the actual problem though.

<!-- gh-comment-id:1292028111 --> @DominikDoom commented on GitHub (Oct 26, 2022): I've added the config option, default is still 100, so you will have to edit the config and set it to 0 there. I'll keep this issue open since it's not solving the actual problem though.

bsakaguchi commented 2026-10-30 21:17:32 +00:00

Author

Owner

Copy link

@DickJokez69 commented on GitHub (Oct 27, 2022):

I haven't tried any of the newer versions, but I also had issues with the autocomplete eating left/right inputs from the arrow keys when the list shows up, making it hard to move the text cursor around if you've made a mistake. up/down I totally understand, but not left/right, since they're not used to navigate that list afaik.

<!-- gh-comment-id:1292867888 --> @DickJokez69 commented on GitHub (Oct 27, 2022): I haven't tried any of the newer versions, but I also had issues with the autocomplete eating left/right inputs from the arrow keys when the list shows up, making it hard to move the text cursor around if you've made a mistake. up/down I totally understand, but not left/right, since they're not used to navigate that list afaik.

bsakaguchi commented 2026-10-30 21:17:32 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 27, 2022):

@DickJokez69 Left and right arrows were used to jump to the first/last result of the list in the past, but that has been turned off by default for a few versions since I added Home/End as a less intrusive alternative.

<!-- gh-comment-id:1293045240 --> @DominikDoom commented on GitHub (Oct 27, 2022): @DickJokez69 Left and right arrows were used to jump to the first/last result of the list in the past, but that has been turned off by default for a few versions since I added Home/End as a less intrusive alternative.

bsakaguchi commented 2026-10-30 21:17:32 +00:00

Author

Owner

Copy link

@thojmr commented on GitHub (Oct 30, 2022):

Wanted to chime in and mentioned I have been having the same issue, and that setting delayTime to 0 does not fix it.

Firefox, windows 10, WSL, plenty of CPU and RAM available

<!-- gh-comment-id:1296078884 --> @thojmr commented on GitHub (Oct 30, 2022): Wanted to chime in and mentioned I have been having the same issue, and that setting delayTime to 0 does not fix it. Firefox, windows 10, WSL, plenty of CPU and RAM available

bsakaguchi commented 2026-10-30 21:17:32 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Oct 30, 2022):

This is such a strange bug, I'm especially confused why I can't reproduce it on my Firefox no matter what I try. It can't be related to typing speed since I couldn't even reproduce it using the AHK script, it can't be settings, cache, or browser extensions since it also happens on safe mode and fresh profiles, it can't be version related since I also tried with the specific build @byzod provided. Hardware seems unlikely too since it also happens with software input in the script and we all have enough specs to run a bit of js. OS also is Win10 for all of us. Language specific problems are also out since it happened in Chinese and English but not for me when I tried it in those two and my own. Delaying the autocompletion seems to have no logical influence on whether it gets better or worse contrary to what I would expect.

At this point I can't really think of anything else that differentiates my setup from others. And yet no matter the delay or speed I've never seen a single letter missed that I didn't mistype myself. This is some haunted PC creepypasta level of illogical.

<!-- gh-comment-id:1296172084 --> @DominikDoom commented on GitHub (Oct 30, 2022): This is such a strange bug, I'm especially confused why I can't reproduce it on my Firefox no matter what I try. It can't be related to typing speed since I couldn't even reproduce it using the AHK script, it can't be settings, cache, or browser extensions since it also happens on safe mode and fresh profiles, it can't be version related since I also tried with the specific build @byzod provided. Hardware seems unlikely too since it also happens with software input in the script and we all have enough specs to run a bit of js. OS also is Win10 for all of us. Language specific problems are also out since it happened in Chinese and English but not for me when I tried it in those two and my own. Delaying the autocompletion seems to have no logical influence on whether it gets better or worse contrary to what I would expect. At this point I can't really think of anything else that differentiates my setup from others. And yet no matter the delay or speed I've never seen a single letter missed that I didn't mistype myself. This is some haunted PC creepypasta level of illogical.

bsakaguchi commented 2026-10-30 21:17:32 +00:00

Author

Owner

Copy link

@thojmr commented on GitHub (Nov 1, 2022):

If it helps, it only occurs when images are being generated, and potentially only when a step is started/ending. Is there any process in your code that is being run on every step of the diffusion? Earlier I remember seeing an error log on every step from your script, but I forgot what caused it to begin with. No error messages in either browser or terminal now though.

<!-- gh-comment-id:1297882740 --> @thojmr commented on GitHub (Nov 1, 2022): If it helps, it only occurs when images are being generated, and potentially only when a step is started/ending. Is there any process in your code that is being run on every step of the diffusion? Earlier I remember seeing an error log on every step from your script, but I forgot what caused it to begin with. No error messages in either browser or terminal now though.

bsakaguchi commented 2026-10-30 21:17:32 +00:00

Author

Owner

Copy link

@byzod commented on GitHub (Nov 1, 2022):

If it helps, it only occurs when images are being generated, and potentially only when a step is started/ending. Is there any process in your code that is being run on every step of the diffusion? Earlier I remember seeing an error log on every step from your script, but I forgot what caused it to begin with. No error messages in either browser or terminal now though.

I barely encounter any swallowing when set delay to 0, but still got many swallowed when image generating. Maybe it is related to performance after all, js/css engine or something

<!-- gh-comment-id:1298094859 --> @byzod commented on GitHub (Nov 1, 2022): > If it helps, it only occurs when images are being generated, and potentially only when a step is started/ending. Is there any process in your code that is being run on every step of the diffusion? Earlier I remember seeing an error log on every step from your script, but I forgot what caused it to begin with. No error messages in either browser or terminal now though. I barely encounter any swallowing when set delay to 0, but still got many swallowed when image generating. Maybe it is related to performance after all, js/css engine or something

bsakaguchi commented 2026-10-30 21:17:32 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Nov 1, 2022):

Is there any process in your code that is being run on every step of the diffusion

Not really. I use just the input change listener of the promt textboxes to trigger the autocomplete.
There is a part that is triggered by Gradio's onUiUpdate function and would run on every step, but that is only for one-time setup after Gradio finished loading and exits out early on every other call. So logically it shouldn't influence performance.

But I'll definitely try if characters are getting missed for me while generating on Firefox, might be a lead if I can reproduce it.

<!-- gh-comment-id:1298428592 --> @DominikDoom commented on GitHub (Nov 1, 2022): > Is there any process in your code that is being run on every step of the diffusion Not really. I use just the input change listener of the promt textboxes to trigger the autocomplete. There *is* a part that is triggered by Gradio's onUiUpdate function and would run on every step, but that is only for one-time setup after Gradio finished loading and exits out early on every other call. So logically it shouldn't influence performance. But I'll definitely try if characters are getting missed for me while generating on Firefox, might be a lead if I can reproduce it.

bsakaguchi commented 2026-10-30 21:17:33 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Nov 1, 2022):

But I'll definitely try if characters are getting missed for me while generating on Firefox, might be a lead if I can reproduce it.

Still no luck, no letters swallowed for me while generating.

I changed the setup code to a one-time call instead of exiting early out of onUIUpdate, so now there should be no code at all running without user input after that one time setup. Doubt it changes anything for this issue but worth a try (and it's cleaner code anyway).

<!-- gh-comment-id:1298474560 --> @DominikDoom commented on GitHub (Nov 1, 2022): > But I'll definitely try if characters are getting missed for me while generating on Firefox, might be a lead if I can reproduce it. Still no luck, no letters swallowed for me while generating. I changed the setup code to a one-time call instead of exiting early out of onUIUpdate, so now there should be no code at all running without user input after that one time setup. Doubt it changes anything for this issue but worth a try (and it's cleaner code anyway).

bsakaguchi commented 2026-10-30 21:17:33 +00:00

Author

Owner

Copy link

@thojmr commented on GitHub (Nov 1, 2022):

I think that change fixed the issue for me. Just grabbed the latest and I have not lost a single character since.

<!-- gh-comment-id:1298695001 --> @thojmr commented on GitHub (Nov 1, 2022): I think that change fixed the issue for me. Just grabbed the latest and I have not lost a single character since.

bsakaguchi commented 2026-10-30 21:17:33 +00:00

Author

Owner

Copy link

@DominikDoom commented on GitHub (Jan 10, 2023):

I'm closing this issue for now since it's been inactive for a while and I haven't gotten new reports in the meantime, but if the problem still exists for one of you, feel free to reopen.

<!-- gh-comment-id:1377374960 --> @DominikDoom commented on GitHub (Jan 10, 2023): I'm closing this issue for now since it's been inactive for a while and I haven't gotten new reports in the meantime, but if the problem still exists for one of you, feel free to reopen.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

refactor-class-scope

feature-fuzzysearch

3.3.0

3.2.0

3.1.0

3.0.0

2.12.0

2.11.0

2.10.6

2.10.5

2.10.1

2.10.0

2.9.0

2.8.0

2.7.5

2.7.4

2.7.3

2.7.2

2.7.1

2.7.0

2.6.0

2.5.1

2.5.0

2.4.0

2.3.0

2.2.0

2.1.0

2.0.0

1.17.0

1.16.2

1.16.1

1.16.0

1.15.0

1.14.0

1.13.0

1.12.1

1.12.0

1.11.2

1.11.1

1.11.0

1.10.1

1.10.0

1.9.2

1.9.1

1.9.0

1.8.2

1.8.1

1.8.0

1.7.3

1.7.2

1.7.1

1.7.0

1.6.0

1.5.1

1.5.0

1.4.3

1.4.2

1.4.1

1.4.0

1.3.0

1.2.2

1.2.1

1.2.0

1.1.0

1.0.1

1.0.0

Labels

Clear labels   

bug

  

duplicate

  

enhancement

  

help wanted

  

invalid

  

low priority

  

low priority

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

waiting for feedback

  

wontfix

No labels

bug

duplicate

enhancement

help wanted

invalid

low priority

low priority

pull-request

question

waiting for feedback

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

DominikDoom/a1111-sd-webui-tagcomplete#30

No description provided.