Comments (38)
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.
from a1111-sd-webui-tagcomplete.
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?
from a1111-sd-webui-tagcomplete.
40d53d8 working confirmed, by setting the debounce delay to 0
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
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:
chrome_2022-10-25_14-22-00.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?
from a1111-sd-webui-tagcomplete.
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
from a1111-sd-webui-tagcomplete.
Alright, thanks for the details. I'll try it on Firefox and see if I can find the cause.
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
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 :/
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
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
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
@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.
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
I tried 1.7.1, still got swallowed, I think we have different issue ;_;
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
1.7.2 seems ok with wildcards disabled. Not getting any swallowed characters.
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
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
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
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?
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
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 :/
from a1111-sd-webui-tagcomplete.
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
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
@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.
from a1111-sd-webui-tagcomplete.
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
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
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
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
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).
from a1111-sd-webui-tagcomplete.
I think that change fixed the issue for me. Just grabbed the latest and I have not lost a single character since.
from a1111-sd-webui-tagcomplete.
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.
from a1111-sd-webui-tagcomplete.
Related Issues (20)
- Is it possible to update danbooru.csv? HOT 1
- (Feature request) stable-diffusion-webui-dataset-tag-editor support update HOT 1
- [Feature request] Fuzzy matching HOT 9
- New tag lists: EnglishDictionary.csv and Derpibooru.csv HOT 3
- Tag Autocomplete: Could not locate model-keyword extension, Lora trigger word completion will be limited to those added through the extra networks menu. HOT 1
- 3.0.0无法弹出tag选项框 HOT 12
- Tag frequency database error - "module scripts.tag_frequency_db not in sys.modules" HOT 8
- XL embedding previews. HOT 4
- Making tagcomplete compatible with wildcard parser-wrap string changes HOT 5
- The extension breaks the ability to go to the beginning and end of a line using the Home and End buttons HOT 1
- Frequency database error - table fails to get created HOT 1
- [Feature Request] Dynamic Tag List Switching HOT 1
- Same name v1 and vXL embedding only show as v1 HOT 2
- 'get_embeddings' issue with symbolic paths (I think) HOT 1
- Mouse hovering on extra network search result not show thumbnails.
- update danbooru.csv? HOT 2
- [WebUI Forge] Cannot reload embeddings instantly HOT 3
- [WebUI Forge] Failed to load module scripts.shared_paths HOT 1
- Extention Not Working At All | Not loading modules HOT 9
- [WebUI ReForge] LoRAs/Checkpoints/Embeddings/UI itself are not refreshing/reloading HOT 19
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from a1111-sd-webui-tagcomplete.