[GH-ISSUE #328] Tag Autocomplete no longer shows after 2nd WebUI launch or so #227

Open
opened 2026-10-30 21:21:17 +00:00 by bsakaguchi · 4 comments
Owner

Originally created by @gingusScringus on GitHub (Jul 8, 2025).
Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/328

I don't know why, but the extension often only works at about the first usage. That is, when I installed it, restarted the whole Web UI, then I use it, it works. But when I decide to terminate the Web UI (Ctrl + C), and start it again at a later time, it no longer works.

I've checked in the settings, and I can confirm that the settings are exactly the default settings. I barely even touched any of them. I tried reinstalling the extension, same issue. I tried installing it the other way, using git clone, because I installed it from the Extensions page in the UI, nope.

My WebUI is running on Pop!_OS 22.04, Linux. I don't really have a lot of extensions apart from these three:

  • Stable-Diffusion-Webui-Civitai-Helper
  • a1111-sd-webui-tagcomplete (this)
  • model-keyword

It's using Python 3.10.12.

Originally created by @gingusScringus on GitHub (Jul 8, 2025). Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/328 I don't know why, but the extension often only works at about the first usage. That is, when I installed it, restarted the whole Web UI, then I use it, it works. But when I decide to terminate the Web UI (Ctrl + C), and start it again at a later time, it no longer works. I've checked in the settings, and I can confirm that the settings are exactly the default settings. I barely even touched any of them. I tried reinstalling the extension, same issue. I tried installing it the other way, using `git clone`, because I installed it from the Extensions page in the UI, nope. My WebUI is running on Pop!_OS 22.04, Linux. I don't really have a lot of extensions apart from these three: - Stable-Diffusion-Webui-Civitai-Helper - a1111-sd-webui-tagcomplete (this) - model-keyword It's using Python 3.10.12.
Author
Owner

@DominikDoom commented on GitHub (Jul 9, 2025):

I can't reproduce what you describe, after CTRL+C and a fresh start it always works just as expected.
Do you keep the browser tab open in the meantime or is it a full fresh start? Does it happen in an incognito tab too? If not it might be a caching issue.

You could try looking in the browser console as well and see if any errors that might be related are logged there. It might not be due to subsequent usages at all but rather a general loading issue or something like that.

Other than that, I wouldn't really know what could cause this other than external influences like browser extensions or webui issues, there were some cases like that before. I won't exclude a bug in tag autocomplete, but it would be very strange if it really only happens on the 2nd launch and onward, most would also affect the first launch.

<!-- gh-comment-id:3053448679 --> @DominikDoom commented on GitHub (Jul 9, 2025): I can't reproduce what you describe, after CTRL+C and a fresh start it always works just as expected. Do you keep the browser tab open in the meantime or is it a full fresh start? Does it happen in an incognito tab too? If not it might be a caching issue. You could try looking in the browser console as well and see if any errors that might be related are logged there. It might not be due to subsequent usages at all but rather a general loading issue or something like that. Other than that, I wouldn't really know what could cause this other than external influences like browser extensions or webui issues, there were some cases like that before. I won't exclude a bug in tag autocomplete, but it would be very strange if it really only happens on the 2nd launch and onward, most would also affect the first launch.
Author
Owner

@gingusScringus commented on GitHub (Jul 10, 2025):

I can't reproduce what you describe, after CTRL+C and a fresh start it always works just as expected. Do you keep the browser tab open in the meantime or is it a full fresh start? Does it happen in an incognito tab too? If not it might be a caching issue.

You could try looking in the browser console as well and see if any errors that might be related are logged there. It might not be due to subsequent usages at all but rather a general loading issue or something like that.

Other than that, I wouldn't really know what could cause this other than external influences like browser extensions or webui issues, there were some cases like that before. I won't exclude a bug in tag autocomplete, but it would be very strange if it really only happens on the 2nd launch and onward, most would also affect the first launch.

Turns out this was because of a Firefox addon that caused this, specifically Audio Equalizer. It seems that the addon might've broke something in the _textAreas.js. I'm not sure why did using another browser or using Incognito didn't cross my mind. My bad.

This is what it looks like on the console with the addon disabled:

Image

And this is what it looks like enabled:

Image

Also randomly while the extension is active:

Image

I don't understand why it also does that randomly. Maybe the extension is coded in a bad way where it sometimes was able to interfere the WebUI and broke something?

So basically, it's not the WebUI or the WebUI extension that is the problem. It's because I was using a faulty Firefox addon for an audio equalizer that somehow broke the WebUI itself. Perhaps there need to be a warning or patch for this if anyone happened to have this addon installed in their browser.

<!-- gh-comment-id:3056558171 --> @gingusScringus commented on GitHub (Jul 10, 2025): > I can't reproduce what you describe, after CTRL+C and a fresh start it always works just as expected. Do you keep the browser tab open in the meantime or is it a full fresh start? Does it happen in an incognito tab too? If not it might be a caching issue. > > You could try looking in the browser console as well and see if any errors that might be related are logged there. It might not be due to subsequent usages at all but rather a general loading issue or something like that. > > Other than that, I wouldn't really know what could cause this other than external influences like browser extensions or webui issues, there were some cases like that before. I won't exclude a bug in tag autocomplete, but it would be very strange if it really only happens on the 2nd launch and onward, most would also affect the first launch. Turns out this was because of a Firefox addon that caused this, specifically [Audio Equalizer](https://addons.mozilla.org/en-US/firefox/addon/audio-equalizer-wext/). It seems that the addon might've broke something in the `_textAreas.js`. I'm not sure why did using another browser or using Incognito didn't cross my mind. My bad. This is what it looks like on the console with the addon disabled: <img width="967" height="262" alt="Image" src="https://github.com/user-attachments/assets/087820d4-6852-410b-84cb-44536f9907fd" /> And this is what it looks like enabled: <img width="967" height="455" alt="Image" src="https://github.com/user-attachments/assets/f2bf89b7-fd59-43a1-a722-cda79417e9fe" /> Also randomly while the extension is active: <img width="967" height="455" alt="Image" src="https://github.com/user-attachments/assets/c4ce9b43-1837-4b44-9058-1ec2f8793715" /> I don't understand why it also does that randomly. Maybe the extension is coded in a bad way where it sometimes was able to interfere the WebUI and broke something? So basically, it's not the WebUI or the WebUI extension that is the problem. It's because I was using a faulty Firefox addon for an audio equalizer that somehow broke the WebUI itself. Perhaps there need to be a warning or patch for this if anyone happened to have this addon installed in their browser.
Author
Owner

@DominikDoom commented on GitHub (Jul 10, 2025):

Ah I see, thanks for the info.

This basically happens because the extension injects some code into the page at runtime (which isn't particularly unusual, many extensions do the same to hook into controls). The issue is that JavaScript code from tag autocomplete is also loaded into the page directly by the webui and not isolated, and clashes with variables from the injected code that have the same name.

From the screenshots, it looks like the second one (where TAC fails completely) is due to the browser extension being the first to load, while the random errors in the third image are the other way around, where TAC was first to reserve that name for itself and the browser extension is the one that fails / throws errors.

It's definitely an issue with the EQ extension that it doesn't isolate itself properly, it will likely break many other websites too which also happen to use "core" as a constant name in some global script.

But it would also be preventable by tag autocomplete itself being better isolated, since it also gets loaded directly into the global namespace. This is the first time this exact type of issue happened with a browser extension, but name conflicts with other webui extensions were fairly common in the past. The reason for that global scope is mostly left-over baggage from the very early times of the webui, where the extension system wasn't a thing yet and the .js files needed to be manually copy-pasted into the correct folder by the user. It might be high time for me to refactor it 😅.

<!-- gh-comment-id:3056698839 --> @DominikDoom commented on GitHub (Jul 10, 2025): Ah I see, thanks for the info. This basically happens because the extension injects some code into the page at runtime (which isn't particularly unusual, many extensions do the same to hook into controls). The issue is that JavaScript code from tag autocomplete is also loaded into the page directly by the webui and not isolated, and clashes with variables from the injected code that have the same name. From the screenshots, it looks like the second one (where TAC fails completely) is due to the browser extension being the first to load, while the random errors in the third image are the other way around, where TAC was first to reserve that name for itself and the browser extension is the one that fails / throws errors. It's definitely an issue with the EQ extension that it doesn't isolate itself properly, it will likely break many other websites too which also happen to use "core" as a constant name in some global script. But it would also be preventable by tag autocomplete itself being better isolated, since it also gets loaded directly into the global namespace. This is the first time this exact type of issue happened with a browser extension, but name conflicts with other webui extensions were fairly common in the past. The reason for that global scope is mostly left-over baggage from the very early times of the webui, where the extension system wasn't a thing yet and the .js files needed to be manually copy-pasted into the correct folder by the user. It might be high time for me to refactor it 😅.
Author
Owner

@gingusScringus commented on GitHub (Jul 10, 2025):

Oh, now I get it. So it just so happens the Equalizer addon often gets first dibs on taking a similar global variable, then it just broke the WebUI like that. I'm no JS developer, but I get the gist of what you mean. In the meantime, I'll just remove the Firefox addon completely, since I figured that I don't have much use for it anyway.

Thanks for the info, too!

<!-- gh-comment-id:3057074410 --> @gingusScringus commented on GitHub (Jul 10, 2025): Oh, now I get it. So it just so happens the Equalizer addon often gets first dibs on taking a similar global variable, then it just broke the WebUI like that. I'm no JS developer, but I get the gist of what you mean. In the meantime, I'll just remove the Firefox addon completely, since I figured that I don't have much use for it anyway. Thanks for the info, too!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
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#227
No description provided.