Double tap required to select/unselect items items about imgui HOT 6 CLOSED

I cannot get the link to load on my iPhone to see what is happening. I see the page but it never loads.

I think you will want to get ShowDebugLogWindow() visible with the [X] IO section checked, and compare between a working setup and non-working one. (Wiki: Debug Tools->Debug Log).

What you describe sounds like a bug that happens when using touch inputs if the input source is not declared as touch, BUT only one some widgets, specifically those using AllowOverlap mode which requires a frame of hover before being interactable. I can't quite explain why this would happen on all widgets as you suggests.

About input source:

• We have a io.AddMouseSourceEvent() function, e.g. io.AddMouseSourceEvent(ImGuiMouseSource_Mouse), io.AddMouseSourceEvent(ImGuiMouseSource_TouchScreen).

// Enumeration for AddMouseSourceEvent() actual source of Mouse Input data.
// Historically we use "Mouse" terminology everywhere to indicate pointer data, e.g. MousePos, IsMousePressed(), io.AddMousePosEvent()
// But that "Mouse" data can come from different source which occasionally may be useful for application to know about.
// You can submit a change of pointer type using io.AddMouseSourceEvent().
enum ImGuiMouseSource : int
{
    ImGuiMouseSource_Mouse = 0,         // Input is coming from an actual mouse.
    ImGuiMouseSource_TouchScreen,       // Input is coming from a touch screen (no hovering prior to initial press, less precise initial press aiming, dual-axis wheeling possible).
    ImGuiMouseSource_Pen,               // Input is coming from a pressure/magnetic pen (often used in conjunction with high-sampling rates).
};

• GLFW backend only submit this information Windows, we have dedicated Win32 code in imgui_impl_glfw.cpp for that (search for AddMouseSourceEvent() call).

What this does: touch screen have no hovering event. If io.AddMousePosEvent() and e.g. a io.AddMouseButtonEvent() down event are submitted on the same frame, with a mouse they will be processed together, while on a touch screen the position will be processed, we let one frame run to allow for AllowOverlap to be hovered once, and then we trickle the mouse down event on the subsequent frame.

Assuming this is the cause of your issue, you would need to find a way to call io.AddMouseSourceEvent(ImGuiMouseSource_TouchScreen) for Emscripten touch inputs. If you do it would be good to share your finding so we can include this in official SDL/GLFW backends that supports Emscripten.

I guess you can add hardcode call for this and see if it fixes the issue. If you left that call in, it would make mouse click deferred by a frame which is not great but technically possible.

However, as stated this tricking was only meant to solve an issue for certain widgets (those using _AllowOverlap button behavior, e.g. Tabs do, and other do based on user flags), not every widgets, so you may have another issue.

Inspecting the debug log you may find some events are out of order? Don't hesitate to share a debug log.

from imgui.

Thanks a lot!

I cannot get the link to load on my iPhone to see what is happening. I see the page but it never loads.

Ah sorry, I never tested it on iOS. Could be that Safari just doesn't support it there.

I think you will want to get ShowDebugLogWindow() visible

My version (Doesn't work)

[03172] [io] Processed: MouseButton 0 Down (Mouse)
[03172] [io] Remaining: MousePos (520.0, 133.0) (Mouse)
[03173] [io] Processed: MousePos (520.0, 133.0) (Mouse)
[03206] [io] Processed: MouseButton 0 Up (Mouse)

The first three messages appear when I put my finger on the display, the last one when I remove it again.

Hello ImGui example (Works)

[01687] [io] Processed: MousePos (359.0, 259.0) (TouchScreen)
[01687] [io] Remaining: MouseButton 0 Down (TouchScreen)
[01688] [io] Processed: MouseButton 0 Down (TouchScreen)
[01717] [io] Processed: MouseButton 0 Up (TouchScreen)

So the main difference seems to be that my version reports the touches as mouse events and theirs as touch events but also the order is different. They're also using the SDL2 backend and not the GLFW3 one.

Manually adding io.AddMouseSourceEvent(ImGuiMouseSource_TouchScreen); in the callbacks in the backend changes the (Mouse) to (TouchScreen) but didn't change anything about the outcome. I'll try to find a way to reorder the MousePos and MouseButton event and see how that goes but these calls come directly from the javascript blob that's generated by emscripten so if it's that, it might be an issue with their GLFW port. I will definitely send a PR either to them or to imgui if I get it to work

from imgui.

Yup, I managed to swap the order the two events were fired in by hacking around in the javascript wrapper a bit. That indeed fixed it. So the MouseButton event needs to be processed one frame after the MousePos event, otherwise touch input will get stuck. The io.AddMouseSourceEvent(ImGuiMouseSource_TouchScreen); is also required for it to work, I'll try to find a way tell imgui if the event came from a touch source

Is there a smart way to change that in imgui / the GLFW backend?

from imgui.

Yes the event order was incorrect.

That indeed fixed it. So the MouseButton event needs to be processed one frame after the MousePos event, otherwise touch input will get stuck.

This is exactly what setting up the mouse source to touch does automatically. Or either you find a way to correctly distinguish mouse vs touch and send events accordingly, either you might lazily set things as touchscreen in Emscripten build for now, or do it based on platform if you can detect that.

from imgui.

Setting the mouse source alone as not enough to make the events be processed in the right order unless I used AddMouseSourceEvent wrong. I just added it above the existing AddMouseXXX functions.

Also hardcoding the event as being from a touch screen is also not really an option because it makes mouse input on desktop in the web version act janky. Doing it manually when detecting a touch input would work but that will be hard to integrate into imgui without glfw being able to send some touchdown/touchup message.

from imgui.

Managed to fix it using a workaround now: WerWolv/ImHex@90bb5d1

For anybody else running into this issue with GLFW and Emscripten in the future, here is what I had to do:

• Added JavaScript event handlers for mousedown and touchstart events that execute C++ functions which call io.AddMouseSourceEvent(ImGuiMouseSource_Mouse) and io.AddMouseSourceEvent(ImGuiMouseSource_TouchScreen) respectively.
• Patched the built-in GLFW.onMousemove and GLFW.onMouseButtonChanged Emscripten GLFW JavaScript event handlers to now trigger both the cursorPos and mouseButton callback in the onMouseButtonChanged callback so they get run in the correct order.

This patch is certainly not perfect but I think with the current GLFW API there's not much else we can do currently. If GLFW ever adds an API for touch inputs, this should definitely be redone and added to the GLFW imgui backend.

from imgui.