Imgui assert when USB keyboard is disconnected

[sarchar]

(you may also go to Demo>About Window, and click "Config/Build Information" to obtain a bunch of detailed information that you can paste here)

Version/Branch of Dear ImGui:

Version: 1.89.6 WIP
Branch: docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_glfw.cpp + imgui_impl_opengl.cpp
Compiler: MSVS Community 2022 17.5.5
Operating System: Win11

My Issue/Question:

I receive the assert whenver my USB keyboard is disconnected while my Dear ImGui application is running:

Assertion failed: (g.IO.DeltaTime > 0.0f || g.FrameCount == 0) && "Need a positive DeltaTime!", file libs\imgui\imgui.cpp, line 9666

I'm sorry I don't have a demo application to share at the moment, but I've been seeing this assert for a long time now and didn't know what caused it. I've now figured out that it happens whenever I disconnect my USB keyboard 100% of the time. If nobody else can reproduce, I'll try to create a barebones app and recreate the issue on something smaller. My application does not do anything special with the keyboard, other than install a keyboard handler in glfw (which I don't use anyway).

[PathogenDavid]

I cannot reproduce this. Does this happen for you with example_glfw_opengl3?

What are the values of DeltaTime and FrameCount?

[sarchar]

For example_glfw_opengl3: yes it does.

[ocornut]

Well I guess for some bizarre reasons this create a situation where glfwGetTime() returns the same value twice.

We added a workaround for this in SDL backends 2496b97 for a different reason (related to Web browser timing attack mitigation in Emscripten apps), so technically I suppose it wouldn't hurt too much if we did the same on the GLFW backend.
I initially wanted to have this assert since it acts as better document for first time custom-backend implementers, but supporting edge case like this is more important anyway.

[sarchar]

Thanks for the insight. It's kind of weird that glfw behaves this way (maybe it's a bug in glfw and they should be notified?). I use a switch to move keyboard and mouse between two different systems, so I see the assert often. I suspect not many do that, though.

[nicolasnoble]

Ooooh, I've totally had user reports who have poorly constructed usb cables that can introduce rapid disconnection / reconnection sometimes. I didn't care this much because, well, get better cables, but it's good to see a fix for it potentially :)

[ocornut]

@nicolasnoble Do you mean/confirm that those user reports had the explicit effect of this assert triggering?

[nicolasnoble]

I can spelunk some of my crash reports to confirm which asserts goes off exactly, but I do recall asserts firing on rapid usb disconnect / reconnects.

[ocornut]

Thanks. Perhaps some side-effects of USB/driver reload stack leads to user-land timing being affected in a way that manifest this way.

[sarchar]

Ooooh, I've totally had user reports who have poorly constructed usb cables that can introduce rapid disconnection / reconnection sometimes. I didn't care this much because, well, get better cables, but it's good to see a fix for it potentially :)

Unfortunately it's not my USB cable. The switch is happening via QEMU.

[ocornut]

Unfortunately it's not my USB cable. The switch is happening via QEMU.

Seems like the same thing, a peripherals connecting or disconnecting.

Either way this makes senses for the same reason as 2496b97 as Emscripten users are likely to stumble on the same thing.
Pushed a fix 884e3fd.

Thanks everyone for helping!