Dragging a selection out of a field (to bring in the part past its
end) and letting go over the backdrop gave the click to the press's and
release's nearest shared ancestor, the backdrop, so every backdrop
handler that checked only e.target closed the dialog.
backdropClick(el, on) in app.js records where the pointer was pressed
and let go, and a click counts as one on the backdrop only when both
were. Every dialog that closes from its backdrop now asks it:
- the shared #modal (provider and other editors, cancelEdit),
- the confirmation that borrows #modal (closeConfirmAsk),
- the library's dialog that borrows #modal (closeLibModal, library.js),
- confirmAction's <dialog> (its ::backdrop is the dialog outside its box).
Menus and pickers close on mousedown outside and were never affected.
Verified:
- new internal/gui/tests/dialog-backdrop-drag.test.cjs, Chromium and
WebKit, en and zh, 1100px and 440px: 8/8 pass. With the change
reverted all 8 fail ("a selection dragged out keeps the dialog");
with only confirmAction reverted they fail on "a selection dragged
out of the confirmation keeps it".
- the whole GUI suite in both engines: the only failures are
purpose-filter in WebKit (fails the same without this change, #1291),
rate-limited-sink "says who is at the back" in WebKit (fails the same
without this change) and library-servers-bulk in Chromium (failed
under the full run only, passes alone).
- real GUI: a magpie built from this tree (`magpie web` under a sandbox
HOME on 127.0.0.1:3486), Chromium and WebKit, zh and en, 440px and
980px: a drag from the provider editor's Name field out over the
backdrop selects the text and leaves the editor open; a click on the
backdrop still closes it.
- go test -tags nogui ./internal/gui under a temp HOME; GOOS=linux and
GOOS=windows go vet -tags nogui ./internal/gui.
yetone
457119fec3