[RPL-NET]

Summary

On phones and tablets, tapping a binary message marker on the map (meteo, AtoN, area…) flashes the message dialog, which closes again at once. Ships work because they open the side card, not the modal.

Cause

The modal dismisses on mousedown on its scrim (frontend/packages/ui/components.js). After a tap, the browser sends compatibility mouse events once the touch ends. The tap itself opened the dialog, so the mousedown that follows lands on the new scrim and closes it.

I reproduced it in Chrome with touch emulation. A MutationObserver on #binary-messages showed the sequence:

pointerup        → class "modal-overlay"          (dialog opens from the map click)
touchend
+3 ms            → class "modal-overlay hidden"   (compat mousedown on the scrim)

Fix

Dismiss on pointerdown instead of mousedown. The tap's pointerdown fires before the dialog exists, so it can't close it. With a mouse, pointerdown fires at the same moment as mousedown, so desktop behaviour doesn't change, and a text selection that ends on the scrim still doesn't dismiss. The comment says why it's not mousedown.

Tested on the viewer with touch emulation and with a mouse. The dialog stays open on tap, and clicking the scrim still closes it with a mouse. The modal is shared with the hub, so the hub's mobile view may be affected too, but I couldn't check that from here.

Source/Web/WebDB.cpp is left un-baked for you to regenerate.

Found while testing #660 on station 3966 (VA2PXR), live at https://ais-catcher.rplnet.ca.

🤖 Generated with Claude Code

https://claude.ai/code/session_01R4CXVA4bmJ9LCW5Ud7FsZJ

[jvde-github]

Thanks, the cause is exactly as you describe. With pointerdown alone, though, the tap that dismisses the dialog also presses whatever is under the scrim (the zoom button, for instance), because the follow-up mouse events arrive after the dialog is gone. I've pushed a variant to main (adec377) that closes on a click that began on the scrim, which avoids both. Closing this in favour of that commit.