mirror of
https://github.com/toeverything/AFFiNE.git
synced 2026-07-02 02:00:49 +08:00
Adarsh Singh
7046ad7bf4
# Closes #14855. ## The bug When an `affine:embed-synced-doc` is placed on an edgeless canvas and resized which sets `model.props.scale` to a value ≠ 1 - the block-selection frame rendered **inside** that embedded editor is drawn offset from the actual block boundary. The reporter hit this in Safari, but the root cause is platform-independent.  ## Root cause `affine-embed-edgeless-synced-doc-block` applies `transform: scale(modelScale)` to its `.affine-embed-synced-doc-container` so the embedded editor visually fits inside its edgeless xywh ([embed-edgeless-synced-doc-block.ts#L48-L58](https://github.com/toeverything/AFFiNE/blob/canary/blocksuite/affine/blocks/embed-doc/src/embed-synced-doc-block/embed-edgeless-synced-doc-block.ts#L48-L58)). The inner `Viewport` exposes that outer scale as `viewScale = boundingClientRect.width / offsetWidth`. PR #14015 and PR #14074 already taught the surface canvas and `GfxBlockComponent.getCSSTransform` to compensate by dividing by `viewScale`. But several selection-related overlays that render inside the same scaled container were **not** updated in those PRs. They either: - read `viewport.toViewCoord(x, y)` - which returns `(x - viewportX) * zoom * viewScale` and drop the result into CSS `left` / `top` inside the scaled container, or - hand-build a `translate(translateX, translateY) scale(zoom)` transform without `viewScale` compensation. The outer CSS `scale(viewScale)` then re-applies the scale, leaving the overlays one factor of `viewScale` away from their blocks. That's exactly the misalignment in the screenshot - the rect's size looks right but its position is offset. ## The fix Mirror the pattern shipped in #14074 everywhere the inner overlays are placed: - position: `(model - viewportX) * zoom / viewScale` - transform scale: `zoom / viewScale` - translate: `translateX / viewScale, translateY / viewScale` This keeps the overlays in the same reference frame as `GfxBlockComponent.getCSSTransform` so they line up with the block they're framing. When `viewScale === 1` (normal edgeless canvas, outside any embed) every `/ viewScale` is a no-op and behaviour is unchanged. ## Why this is safe - When `viewScale === 1` - every existing caller outside `embed-edgeless-synced-doc` - the math reduces to the original expression byte-for-byte. - The fix strictly mirrors the invariant already adopted by `GfxBlockComponent.getCSSTransform` in #14074. It's the same division by `viewScale` applied in the same place. - No public API, type, or DOM structure changed. ## Scope / known limitations - The `Viewport._cachedBoundingClientRect` cache is only invalidated by its own `ResizeObserver` ([viewport.ts#L500-L505](https://github.com/toeverything/AFFiNE/blob/canary/blocksuite/framework/std/src/gfx/viewport.ts#L500-L505)). A CSS-transform change on an ancestor (e.g. the user panning/zooming the outer edgeless canvas) does not fire it, so in theory `viewScale` can go stale between outer-viewport updates. In practice this hasn't come up in repro - the inner viewport's shell is observed and fires whenever layout shifts. If it turns out to matter I'm happy to add a `viewport.onResize()` refresh hook off the existing `GfxViewportInitializer` in a follow-up. - No integration test added - the existing `blocksuite/integration-test/edgeless/` suite has no `embed-synced-doc` harness. Adding one is a larger scope; can follow up if requested. ## Test plan - [x] `yarn typecheck` - passes - [x] `yarn lint:ox` - `0 warnings, 0 errors` - [x] `yarn prettier --write` on the 5 touched files - no changes - [ ] Manual: on canary, create an edgeless canvas, drop an embed-synced-doc, resize with `Shift` held so `model.props.scale` ≠ 1, select any block inside, and verify the blue selection frame sits flush with the block's boundary (confirm on Safari, Chrome, Firefox). - [ ] Regression check: on a normal edgeless canvas (no embed), verify element selection, drag handle, and text/shape inline editors still render correctly (these code paths hit `viewScale === 1` and should be unchanged). ## Related PRs - #14015 - fixed surface canvas at non-1 `viewScale`. - #14074 - fixed `GfxBlockComponent.getCSSTransform` at non-1 `viewScale`. This PR completes that series by covering the selection overlays. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Fixed positioning and scaling of inline text editors, selection rectangles, drag handles, and remote cursors so overlays and editors remain correctly aligned and sized when the viewport uses an additional outer scale/transform during zooming and panning. <!-- end of auto-generated comment: release notes by coderabbit.ai -->