From 7d68a82e88e5fd9aeafe9b19928c88a1a4ebafe1 Mon Sep 17 00:00:00 2001 From: kirillDevPro <113171057+kirillDevPro@users.noreply.github.com> Date: Fri, 16 Oct 2026 06:04:07 +0200 Subject: [PATCH 1/2] docs(gpui): record press-suppressed tooltips in the patch queue What was stale: MOON_PATCH_QUEUE lists the Moon GPUI patches a Zed re-sync must keep, but the tooltip entry described only the 800 ms show delay, the five-second expiry and hoverable persistence. #119 (0c4a7c4) added a Moon-only behaviour that a re-sync would silently drop. What the code does now: a mouse press on a regular tooltip's trigger replaces its state with SuppressedUntilMouseLeaves (hiding it or cancelling a pending show); TooltipTrigger::check_can_show gates showing while check_is_hovered alone clears the suppression once the pointer leaves, even with the button held. Upstream only cleared the tooltip on press and let the next pointer move after release schedule it again. Verified against crates/moon-gpui/src/elements/div.rs (register_tooltip_mouse_handlers, handle_tooltip_mouse_move) and the pre-change code in 0c4a7c4^. cargo xtask component-mirror and component-audit --check-baseline both PASS. Reviewer: Codex. It disputed the first wording of the upstream sentence (release does not itself reschedule; the next pointer move does); the sentence was corrected to match. --- docs/MOON_PATCH_QUEUE.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/MOON_PATCH_QUEUE.md b/docs/MOON_PATCH_QUEUE.md index 2b2fe98..237368d 100644 --- a/docs/MOON_PATCH_QUEUE.md +++ b/docs/MOON_PATCH_QUEUE.md @@ -57,6 +57,13 @@ cargo xtask transform --zed-tag v0.0.0 --zed-path R:\test\_zed_gpui_base_84b753 - regular pointer tooltips require 800 ms of continuous hover, expire after five visible seconds, and stay suppressed until pointer re-entry; hoverable tooltips remain persistent while either their trigger or content is hovered. + A mouse press on the trigger of a regular tooltip hides it, or cancels the + pending show, and keeps it suppressed until the pointer leaves the trigger, + even with the button still held (`TooltipTrigger` in + `moon-gpui/src/elements/div.rs`: `check_can_show` gates showing, + `check_is_hovered` clears the suppression). Upstream only clears the + tooltip on press; after the release the next pointer move over the + trigger schedules it again without the pointer leaving. - `UniformList::on_visible_range`: a channel for observing the item range the list draws. The renderer closure cannot serve as one — `measure_item` runs it on a single item, twice per frame, before the real range exists — so a From 0da2990943d6dbd5236a0dfc9d75336eacc1f65d Mon Sep 17 00:00:00 2001 From: kirillDevPro <113171057+kirillDevPro@users.noreply.github.com> Date: Fri, 16 Oct 2026 06:09:24 +0200 Subject: [PATCH 2/2] fix(moon-util): reject Windows drive roots in RelPath::new Input: RelPath::new(Path::new("C:\\"), PathStyle::Windows), also "C:/" and "d:\\\\". Wrong output: Ok("C:"). RelPath::new trimmed trailing separators before its absolute-path check, so the drive root lost the separator that paths::is_absolute needs (letter, colon, separator) and was accepted as a relative path. PathStyle::strip_prefix with an empty parent handed the drive root out as Some("C:"). Expected output: an error. The function's doc says it returns an error if the path is absolute, and paths::is_absolute("C:\\", Windows) is true; C:\foo and C:\. were already rejected. The fix checks is_absolute on the input before trimming. It changes the result only for a drive letter and colon followed by nothing but separators; every other input takes the same path as before. Test: rel_path::rel_path_tests::new_rejects_a_windows_drive_root failed before the fix ("C:\\" is an absolute drive root, not a relative path) and passes now. Re-run: cargo test -p moon-util --lib new_rejects_a_windows_drive_root Reviewer: Codex. --- crates/moon-util/src/rel_path.rs | 5 +++++ crates/moon-util/src/rel_path/rel_path_tests.rs | 16 ++++++++++++++++ 2 files changed, 21 insertions(+) diff --git a/crates/moon-util/src/rel_path.rs b/crates/moon-util/src/rel_path.rs index e0e2625..8e15c39 100644 --- a/crates/moon-util/src/rel_path.rs +++ b/crates/moon-util/src/rel_path.rs @@ -52,6 +52,11 @@ impl RelPath { #[track_caller] pub fn new<'a>(path: &'a Path, path_style: PathStyle) -> Result> { let mut path = path.to_str().context("non utf-8 path")?; + // Check before trimming trailing separators: trimming turns the drive + // root `C:\` into `C:`, which no longer reads as absolute. + if is_absolute(path, path_style) { + return Err(anyhow!("absolute path not allowed: {path:?}")); + } let (prefixes, suffixes): (&[_], &[_]) = match path_style { PathStyle::Posix => (&["./"], &['/']), diff --git a/crates/moon-util/src/rel_path/rel_path_tests.rs b/crates/moon-util/src/rel_path/rel_path_tests.rs index 97136a3..c23976c 100644 --- a/crates/moon-util/src/rel_path/rel_path_tests.rs +++ b/crates/moon-util/src/rel_path/rel_path_tests.rs @@ -221,3 +221,19 @@ fn from_proto_accepts_only_an_already_normalized_relative_path() { "an absolute path is not a relative wire path" ); } + +/// Catches `RelPath::new` stripping trailing separators before it checks for an +/// absolute path, so the Windows drive root `C:\` (absolute by +/// `paths::is_absolute`: drive letter, colon, separator) loses its separator and +/// is accepted as the relative path `C:`. `C:\foo` and `C:\.` are rejected, so +/// the bare root must be too; a caller such as `PathStyle::strip_prefix` would +/// otherwise hand out a drive root as a path inside the worktree. +#[test] +fn new_rejects_a_windows_drive_root() { + for root in ["C:\\", "C:/", "d:\\\\"] { + assert!( + super::RelPath::new(std::path::Path::new(root), PathStyle::Windows).is_err(), + "{root:?} is an absolute drive root, not a relative path" + ); + } +}