chore(deps): bump js-yaml from 4.3.0 to 4.3.1 in /docs - #141
Closed
dependabot[bot] wants to merge 1 commit into
Closed
dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [js-yaml](https://github.com/nodeca/js-yaml) from 4.3.0 to 4.3.1. - [Changelog](https://github.com/nodeca/js-yaml/blob/4.3.1/CHANGELOG.md) - [Commits](nodeca/js-yaml@4.3.0...4.3.1) --- updated-dependencies: - dependency-name: js-yaml dependency-version: 4.3.1 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
mpiton
added a commit
to kueschallCarl/tauri-pilot
that referenced
this pull request
Aug 30, 2026
Replaces `dispatchPointerPair` with a thin wrapper over the existing `dispatchPointerEvent`. That fixes four things at once: pointer events now precede their compatibility mouse events as the spec (and `click()`) has them, `composed: true` lets the press escape a shadow root, a WebView without the `PointerEvent` constructor still gets pointer-typed events instead of nothing, and a cancelled pointer event suppresses its mouse counterpart. The unused `accepted` return is gone with it. The press target is now gated on containment. `elementFromPoint` hands back whatever is on top, so a toast or backdrop over the source would take the press while `drag` still returned ok — the false green this change exists to remove. Moves and the release are hit-tested per point instead of going to `document`. Dispatching on `document` gives the event a propagation path of `[window, document]` and nothing else, so listeners on elements between the pressed node and the document never fire; React 17+ delegates on its root container, not on `document`. They still bubble to the document-level listeners dnd-kit and friends install. The step delay no longer runs after the last move, where it separates nothing and only pushes the drop sequence back. `steps`, `stepDelayMs` and `settleMs` are declared in the MCP drag schema and forwarded, which the docs already claimed. The plugin sizes the eval timeout from them, so a gesture tuned past 10s is no longer cut short by the channel while the bridge is still mid-drag. Drops the `mpiton#141` references from the test file — that issue is a js-yaml dependabot bump, not this bug.
mpiton
added a commit
that referenced
this pull request
Aug 30, 2026
…braries (#142) * fix(bridge): make drag a real pointer gesture so it drives JS drag libraries `drag` dispatched the HTML5 DragEvent sequence plus a single `mousedown`, with no `mousemove` stream and no `mouseup`, then returned `ok: true` unconditionally. That drives `draggable="true"` handlers, but not the other family of drag implementation: dnd-kit, sortable.js, interact.js and react-dnd's mouse backend never see DragEvents. They activate on `mousedown`, track *repeated* `mousemove`/`pointermove` events on `document` behind a small distance threshold, and commit on `mouseup`. A press with no movement and no release cannot activate them, so `tauri-pilot drag` against such an app did nothing and reported success — the worst outcome for an agent asserting on the result. The gesture now: * presses the deepest node under the start point (`elementFromPoint`) rather than the resolved element — library listeners commonly sit on an inner handle or card, and events only bubble upward, so pressing the container misses them; * streams interpolated `mousemove`/`pointermove` events on `document` with `buttons: 1`, clearing distance thresholds (`document` because a `position: fixed` ancestor can otherwise break pointer capture in WKWebView); * emits the HTML5 sequence exactly as before, so native handlers do not regress; * releases with `mouseup`/`pointerup`, then waits for the app to settle, since a library drop commonly triggers async state/network work before the DOM updates. `steps` (1–60, default 12), `stepDelayMs` (default 16) and `settleMs` (default 250) tune it. `drag` is now async; the eval wrapper already awaits results, so the protocol is unchanged. The result gains `from`, `to`, `steps` and `html5DropHandled` (true when a handler called `preventDefault()` on the drop). `ok` still means only that the gesture was delivered — nothing observable from outside can prove a library handled a drop — and the docs now say so instead of implying success. PointerEvent is used only when the constructor exists, so a WebView without it degrades to mouse-only events rather than throwing. Verified against a real Tauri v2 + React app on macOS (WKWebView) using @dnd-kit/core 6.3.1 with MouseSensor and a 6px activation distance: before this change `tauri-pilot drag <source> <target>` printed `ok` and changed nothing; after it, the dragged item lands in the drop zone and the resulting row is present in the app's SQLite database. * fix(bridge): address review on the drag gesture Replaces `dispatchPointerPair` with a thin wrapper over the existing `dispatchPointerEvent`. That fixes four things at once: pointer events now precede their compatibility mouse events as the spec (and `click()`) has them, `composed: true` lets the press escape a shadow root, a WebView without the `PointerEvent` constructor still gets pointer-typed events instead of nothing, and a cancelled pointer event suppresses its mouse counterpart. The unused `accepted` return is gone with it. The press target is now gated on containment. `elementFromPoint` hands back whatever is on top, so a toast or backdrop over the source would take the press while `drag` still returned ok — the false green this change exists to remove. Moves and the release are hit-tested per point instead of going to `document`. Dispatching on `document` gives the event a propagation path of `[window, document]` and nothing else, so listeners on elements between the pressed node and the document never fire; React 17+ delegates on its root container, not on `document`. They still bubble to the document-level listeners dnd-kit and friends install. The step delay no longer runs after the last move, where it separates nothing and only pushes the drop sequence back. `steps`, `stepDelayMs` and `settleMs` are declared in the MCP drag schema and forwarded, which the docs already claimed. The plugin sizes the eval timeout from them, so a gesture tuned past 10s is no longer cut short by the channel while the bridge is still mid-drag. Drops the `#141` references from the test file — that issue is a js-yaml dependabot bump, not this bug. * fix(plugin): match the bridge steps fallback in the drag timeout `bridge.js` sends any `steps` below 1 back to its default of 12, but the Rust budget clamped it to 1. A `steps: 0, stepDelayMs: 1000` call therefore got a 10s channel while the bridge still had 12s of move delays to run, which is the same dropped-result failure the budget was added to prevent. Zero is now mapped to 12 before the upper clamp. The trailing-delay test recorded wall-clock time with an upper bound, which a paused event loop can blow through on a correct gesture. It now captures what the gesture schedules instead and asserts the exact sequence of sleeps, which is deterministic and pins the settle as well. * fix(plugin): coerce drag tunables like the bridge does `bridge.js` runs steps/stepDelayMs/settleMs through `Number()`, so a numeric string or a fractional value is a real setting there. `drag_eval_timeout` read them with `as_u64`, which returns None for both, so `stepDelayMs: "1000"` on a 60-step gesture budgeted the 10 s floor against a 60 s drag and timed the channel out mid-drag. Mirror the coercion instead: parse numeric strings, keep fractions, floor only `steps`. * fix(plugin): read radix-prefixed drag tunables like Number() does `Number("0x3e8")` is 1000, so a hex literal is a real one-second step delay in the bridge while `f64::from_str` rejected it and the budget dropped back to the 10 s floor. Same failure the decimal-string fix addressed, one string form further out. Also corrects the coercion note above `field`: `Number(true)` is 1, not 0. * fix(plugin): drop the width cap on radix drag tunables `Number()` puts no width limit on `0x`/`0o`/`0b` literals, and `steps` clamps to 60 afterwards, so parsing into u32 sent `steps: "0xFFFFFFFFFF"` back to the default of 12 while the bridge ran the full 60. Accumulate into f64 instead, and reject a bare prefix the way `Number("0x")` does. --------- Co-authored-by: Mathieu Piton <27002047+mpiton@users.noreply.github.com>
Owner
|
@dependabot rebase |
Author
|
Looks like js-yaml is up-to-date now, so this is no longer needed. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps js-yaml from 4.3.0 to 4.3.1.
Changelog
Sourced from js-yaml's changelog.
Commits
86e91b84.3.1 releasedc3cc4b0Backport quadratic complexity fix for !!omapDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.
Summary by cubic
Upgrade
js-yamlto 4.3.1 in docs to pull in a security fix for!!omapduplicate key detection. This lowers worst‑case parse cost and reduces potential DoS risk.Written for commit 0e6ea19. Summary will update on new commits.