vladmandic
[Issue]: Dropdown issue (active but invisible)
Issue Description
I'm not quite sure if this a Gradio issue or something with this repo. For an amount of time now, I noticed, that sometimes, when using a dropdrown (mainly checkpoints in quick select and embeddings in training) and selecting an entry, the dropdown gets invisible, but stays open. When then clicking something beneath the dropdown, an entry on where the click was, is triggered, resulting in a change of the checkpoint or, where I experience it mostly, a different embedding when doing a training.
I can't really reproduce this consistently and I can't say in what situation it is causing this, it just "happens" sometimes. Anyone noticed this, too?
Version Platform Description
Win10, FF 106 Version: b6289d56 Sat May 20 13:36:27 2023 -0400
i've tried playing around with it as you've noted, but i cannot reproduce. but there is nothing specific to that control in this repo, its a https://gradio.app/docs/#dropdown, so if there is an issue, its a gradio issue.
Hmm .. OK, I thought about a Gradio issue (what a crap app). I will try to observe this, maybe I catch when it triggers. Thanks for looking into it.
Update: Something that almost always works is as following: Change the checkpoint to any other and wait until it's loaded, then press the generate button but have your eyes at the dropdown. You should see the dropdown flash for a fraction of a second.
I can confirm, I have some dropdown issues in Firefox as well. When I select a model from the dropdown, the dropdown does not really close, or it opens again or something. I always have to click away for it to close.
I agree, after selecting and then model finishing to load from the dropdown list, the list would re-appear, I have to click on the neutral area to actually close it (luckily the chosen model stays chosen). I noticed it on the gradio-soft theme. Also, I noticed this drop-down list is the only one, that doesn't "follow" the model choice - the list is displayed always at the beginning after opening. :)
This also exists in a1111. Clicking out of the browser after selecting a model and returnung back to it also cause this. In my case I accidentaly clicked on another model countless times, since the drop down is not visible. Probably gradio related.
It still exists and it's definitely a Gradio problem, because it happens on all Gradio based UIs. I can't understand why this bug is still existing after such along time. The Gradio devs seem not really to care about this often severe problem.
can you check if issue still exists?
For me, I did encounter it a number of times on 3.3x AND WebSockets ON, on latest Gradio 3.4x it remains to be seen. 🙂 I probably should upgrade the CPU/platform, so it doesn't drag, because without WebSockets the UI is more responsive, but I was getting a LOT of "cannot [something] because the state is ERROR" - certainly it was referring to some sort of timeouts.
Ugh, even on WebSockets I can see that sometimes. 🙂
18:57:54-036480 ERROR Exception in callback H11Protocol.timeout_keep_alive_handler()
handle: <TimerHandle when=8081.078 H11Protocol.timeout_keep_alive_handler()>
╭─────────────────────────────────────── Traceback (most recent call last) ───────────────────────────────────────╮
│ C:\Users\Mik\AppData\Local\Programs\Python\Python310\lib\asyncio\events.py:80 in _run │
│ │
│ 77 │ │
│ 78 │ def _run(self): │
│ 79 │ │ try: │
│ ❱ 80 │ │ │ self._context.run(self._callback, *self._args) │
│ 81 │ │ except (SystemExit, KeyboardInterrupt): │
│ 82 │ │ │ raise │
│ 83 │ │ except BaseException as exc: │
│ │
│ X:\AI\automatic\venv\lib\site-packages\uvicorn\protocols\http\h11_impl.py:363 in timeout_keep_alive_handler │
│ │
│ 360 │ │ """ │
│ 361 │ │ if not self.transport.is_closing(): │
│ 362 │ │ │ event = h11.ConnectionClosed() │
│ ❱ 363 │ │ │ self.conn.send(event) │
│ 364 │ │ │ self.transport.close() │
│ 365 │
│ 366 │
│ │
│ X:\AI\automatic\venv\lib\site-packages\h11\_connection.py:512 in send │
│ │
│ 509 │ │ :ref:`error-handling` for discussion. │
│ 510 │ │ │
│ 511 │ │ """ │
│ ❱ 512 │ │ data_list = self.send_with_data_passthrough(event) │
│ 513 │ │ if data_list is None: │
│ 514 │ │ │ return None │
│ 515 │ │ else: │
│ │
│ X:\AI\automatic\venv\lib\site-packages\h11\_connection.py:537 in send_with_data_passthrough │
│ │
│ 534 │ │ │ # they will only receive valid events. But, _process_event might │
│ 535 │ │ │ # change self._writer. So we have to do a little dance: │
│ 536 │ │ │ writer = self._writer │
│ ❱ 537 │ │ │ self._process_event(self.our_role, event) │
│ 538 │ │ │ if type(event) is ConnectionClosed: │
│ 539 │ │ │ │ return None │
│ 540 │ │ │ else: │
│ │
│ X:\AI\automatic\venv\lib\site-packages\h11\_connection.py:272 in _process_event │
│ │
│ 269 │ │ server_switch_event = None │
│ 270 │ │ if role is SERVER: │
│ 271 │ │ │ server_switch_event = self._server_switch_event(event) │
│ ❱ 272 │ │ self._cstate.process_event(role, type(event), server_switch_event) │
│ 273 │ │ │
│ 274 │ │ # Then perform the updates triggered by it. │
│ 275 │
│ │
│ X:\AI\automatic\venv\lib\site-packages\h11\_state.py:293 in process_event │
│ │
│ 290 │ │ │ _event_type = (event_type, server_switch_event) │
│ 291 │ │ if server_switch_event is None and _event_type is Response: │
│ 292 │ │ │ self.pending_switch_proposals = set() │
│ ❱ 293 │ │ self._fire_event_triggered_transitions(role, _event_type) │
│ 294 │ │ # Special case: the server state does get to see Request │
│ 295 │ │ # events. │
│ 296 │ │ if _event_type is Request: │
│ │
│ X:\AI\automatic\venv\lib\site-packages\h11\_state.py:311 in _fire_event_triggered_transitions │
│ │
│ 308 │ │ │ new_state = EVENT_TRIGGERED_TRANSITIONS[role][state][event_type] │
│ 309 │ │ except KeyError: │
│ 310 │ │ │ event_type = cast(Type[Event], event_type) │
│ ❱ 311 │ │ │ raise LocalProtocolError( │
│ 312 │ │ │ │ "can't handle event type {} when role={} and state={}".format( │
│ 313 │ │ │ │ │ event_type.__name__, role, self.states[role] │
│ 314 │ │ │ │ ) │
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
LocalProtocolError: can't handle event type ConnectionClosed when role=SERVER and state=SEND_RESPONSE
..and then
18:57:54-791383 ERROR HTTP API: LocalProtocolError
╭─────────────────────────────────────────────────── Traceback (most recent call last) ────────────────────────────────────────────────────╮
│ X:\AI\automatic\venv\lib\site-packages\starlette\middleware\errors.py:162 in __call__ │
│ │
│ X:\AI\automatic\venv\lib\site-packages\starlette\middleware\base.py:109 in __call__ │
│ │
│ X:\AI\automatic\venv\lib\site-packages\starlette\responses.py:270 in __call__ │
│ │
│ X:\AI\automatic\venv\lib\site-packages\anyio\_backends\_asyncio.py:597 in __aexit__ │
│ │
│ X:\AI\automatic\venv\lib\site-packages\starlette\responses.py:273 in wrap │
│ │
│ ... 1 frames hidden ... │
│ │
│ X:\AI\automatic\venv\lib\site-packages\starlette\responses.py:255 in stream_response │
│ │
│ X:\AI\automatic\venv\lib\site-packages\starlette\middleware\errors.py:159 in _send │
│ │
│ X:\AI\automatic\venv\lib\site-packages\uvicorn\protocols\http\h11_impl.py:490 in send │
│ │
│ X:\AI\automatic\venv\lib\site-packages\h11\_connection.py:512 in send │
│ │
│ 511 │ │ """ │
│ ❱ 512 │ │ data_list = self.send_with_data_passthrough(event) │
│ 513 │ │ if data_list is None: │
│ │
│ X:\AI\automatic\venv\lib\site-packages\h11\_connection.py:527 in send_with_data_passthrough │
│ │
│ 526 │ │ if self.our_state is ERROR: │
│ ❱ 527 │ │ │ raise LocalProtocolError("Can't send data when our state is ERROR") │
│ 528 │ │ try: │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
LocalProtocolError: Can't send data when our state is ERROR
18:57:54-915383 ERROR API error: GET:
http://localhost:7860/sd_extra_networks/thumb?filename=X%3A/AI/automatic/models/Lora/deepStyle_v1.thumb.jpg&mtime=1
688068176.6611845 {'error': 'LocalProtocolError', 'detail': '', 'body': '', 'errors': "Can't send data when our
state is ERROR"}
18:57:54-918883 ERROR HTTP API: LocalProtocolError
╭─────────────────────────────────────────────────── Traceback (most recent call last) ────────────────────────────────────────────────────╮
│ X:\AI\automatic\venv\lib\site-packages\starlette\middleware\errors.py:162 in __call__ │
│ │
│ X:\AI\automatic\venv\lib\site-packages\starlette\middleware\base.py:109 in __call__ │
│ │
│ X:\AI\automatic\venv\lib\site-packages\starlette\responses.py:270 in __call__ │
│ │
│ X:\AI\automatic\venv\lib\site-packages\anyio\_backends\_asyncio.py:597 in __aexit__ │
│ │
│ X:\AI\automatic\venv\lib\site-packages\starlette\responses.py:273 in wrap │
│ │
│ ... 1 frames hidden ... │
│ │
│ X:\AI\automatic\venv\lib\site-packages\starlette\responses.py:255 in stream_response │
│ │
│ X:\AI\automatic\venv\lib\site-packages\starlette\middleware\errors.py:159 in _send │
│ │
│ X:\AI\automatic\venv\lib\site-packages\uvicorn\protocols\http\h11_impl.py:490 in send │
│ │
│ X:\AI\automatic\venv\lib\site-packages\h11\_connection.py:512 in send │
│ │
│ 511 │ │ """ │
│ ❱ 512 │ │ data_list = self.send_with_data_passthrough(event) │
│ 513 │ │ if data_list is None: │
│ │
│ X:\AI\automatic\venv\lib\site-packages\h11\_connection.py:527 in send_with_data_passthrough │
│ │
│ 526 │ │ if self.our_state is ERROR: │
│ ❱ 527 │ │ │ raise LocalProtocolError("Can't send data when our state is ERROR") │
│ 528 │ │ try: │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
LocalProtocolError: Can't send data when our state is ERROR
Sorry about this LONG report, but I wanted to show what I see, and explain, how it happens and maybe this could be the reason on [slower one CPU thread] machines? It happened after I had SD.Next opened in a Brave's tab, then monitor went to OFF/SLEEP state (GPU stops updating the screen then). The OS doesn't go to sleep though. And after waking up the monitors (by mouse move) I had to Ctrl+F5 to actually be able to use the (fully loaded by then) UI at all, and when I did that, I got "attacked" with the multiple "servings" of these two errors. 🙂
Of course, when I'm on PC and don't allow the monitors to OFF themselves, the errors won't show, unless I use --disable-queue (no WebSockets) - then they might pop up nonetheless, even if I'm just waiting for the UI to become responsive.
Sorry about this LONG report, but I wanted to show what I see, and explain, how it happens:
nothing wrong with long when its up-to-the-point.
but...this kinda makes sense - all modern browsers implement power saving by suspending tabs which are not in focus. and when your monitor goes to sleep, browser detects its no longer visible so it suspends sdnext tab. which means that communication server<->browser is interrupted and you get exactly what you see - disconnected websocket.
now, that should be handled internally by low-level protocol, but default libraries that are used are gradio->fastapi->asyncio->h11 (in that order going from high-level to low-level). there are far better options in python than h11 and i'm experimenting with them for api access, but i cant change what is used by gradio (and not to blame them, its the default set by fastapi as well).
but all-in-all, unfortunate but kind of expected - only way to get out of that is to reload page.
and you can also dig through browser flags, perhaps you can tell brave not to suspend inactive tab.
That's exactly what I set for the SD.Next tab, or rather "localhost" - "do not put to sleep that tab!". 🙂 But it happened anyway. Thank you for the detailed explanation! I wonder, if I went for faster CPU (I have 7th gen Intel at the moment, so it might be time to think about the upgrade), would that change things a bit?
7th gen? hmm...normally i'd say no, but that's quite old - issue is not speed, but lack of more modern cpu instruction set.
It has AVX and AVX2, as every modern CPU, but the IPC is on the level of, I'd say, between Ryzen 1xxx and 2xxx?
This is something Kubuxu and I, at least, are aware of, it happens pretty much anytime you do something on another monitor when you have more than one, at least that's what we narrowed it down to AFAIK. Very easy to reproduce that way.
Oho, just encountered it, on ce0be4a2 commit.
I just copied a new model file into the \others folder, and refreshed the model list. Then attempted to load the freshly copied model (the file itself was long since copied already). And - voila! 🙂 I have to admit, that I went away from the PC for some time, and OS turned off both monitors, as usual. Brave didn't put that tab to sleep, as I forbade it to.
The shell window doesn't even show the loading process of that model I've chose, the whole process just froze. I'll attempt it with Extra Networks add-on.
Edit: the add-on allowed me to load the model and I can generate images, but model list is unusable (it drops down and I can select another model, but it won't load; no errors in
sdnext.log):
Sounds like suspend happens (at least partially) regardless of your browser settings once monitor goes to sleep...
Though, I did generate an image just before changing the model to the one on the screenshot. :)
now that we're closer to understanding the issue, i'm removing cannot reproduce flag, but i still cant do much to fix it.