mirror of
https://github.com/NanmiCoder/cc-haha
synced 2026-07-31 16:33:34 +08:00
ced096c894
8a3ea62b taught dragging to clamp against the mascot rather than the whole window, so a saved edge position deliberately leaves the transparent padding off-screen. Recreating the window re-clamps that position against the whole window again, and the reposition-on-restore step that undoes it was gated on darwin -- so on Windows and Linux the mascot walked inwards by the padding width on every hide/show, not just on restart. The gate only existed because visibleDragRegion used to be darwin-only; the region now arrives everywhere, so the repositioning runs everywhere. e24d59fe restated the recorded window size on every drag tick to stop setPosition from growing the window, but sampled that size from getBounds(). Chromium converts window rects between physical pixels and DIP with ceil in both directions, so the sampled value has already been rounded up once and restating it rounds up again: stable within a drag, a pixel per drag across them. The window is created non-resizable at the nominal size, so restating the constants is idempotent instead -- and heals a window that already drifted. Both call sites now go through movePetWindow. petWindowContentExtent fell back to the nominal constants when getContentBounds returned an empty rect, which silently reinstates the exact clamp it exists to avoid. Fall through to the live window box first. The fake window in the tests returned one object for both getBounds and getContentBounds, and modelled setBounds as inherently size-neutral -- so neither "clamp to the content box" nor "size-neutral drag" was actually proven: reverting either left all 33 tests green. It now models the ceil/ceil DIP round trip and carries a distinct content box, and covers the previously untested paths: cross-platform restore, multi-region shapes, the region normalization bounds, and the getContentBounds fallbacks.