### Problem
●In edgeless mode, after clicking and moving in a connector's label
editor, if the label editor has empty content at the end of the editing,
the label editor for that connector can not be triggered again.
●The following video demonstrates this issue:
https://github.com/user-attachments/assets/8d300720-5ed8-4f9c-90fa-fbf059417ff8
### Root Cause
**Direct cause**
●The `labelOffset` property is **stashed** at drag-start, but is **not
properly popped** afterward. As a result, when
`mountConnectorLabelEditor()` is called the second time
(`packages/affine/gfx/connector/src/text/edgeless-connector-label-editor.ts`),
`connector.labelOffset` returns `undefined` instead of the default value
provided by the `@field` decorator.
**Why moving after clicking incorrectly triggers a drag-start**
●The root issue lies in the interaction between click and drag event
handling. Here's the actual flow:
1.`dispatcher.add('click', () => true)` is registered in
`EdgelessConnectorLabelEditor`.
2.On pointer-down, both `ClickController` and `DragController` receive
the event.
3.On pointer-up, `ClickController` fires a **synthetic click**. The
handler from step 1 returns `true`, triggering
`context.get('defaultState').event.stopPropagation()`.
4.This prevents the native pointer-up from bubbling to `DragController`.
However, a subsequent pointer-move still causes `DragController` to
**incorrectly synthesize a drag-start + drag-move**.
**Fundamental root cause**
●The line `context.get('defaultState').event.stopPropagation()` in
`UIEventDispatcher::run()` stops **both** synthetic and native event
bubbling. It should only stop synthetic event propagation.
●The synthetic event bubbling stopping is already properly handled by
the immediate `return` statement on the next line, because the runners
are prepared in strict order (current → parent → grandparent → ... →
global) by `UIEventDispatcher::_getEventScope()` and then **executed
sequentially** in `UIEventDispatcher::run()`.
### Fix
●Since I cannot rule out that other (current or future) event handlers
may rely on this native event bubbling stopping behavior, I chose not to
remove the `context.get('defaultState').event.stopPropagation()` line
completely. Instead, I added a new constant and now skip
`stopPropagation()` **only** for the following synthetic events:
```ts
const syntheticEventNames = new Set(['click', 'doubleClick', 'tripleClick']);
```
These currently represent all known synthetic click events triggered
from pointer-up.
### After
●The video below shows the behavior after this fix.
https://github.com/user-attachments/assets/65b8a3ce-0767-4d80-986b-8bc6081ddd4c
### Problem
●In edgeless mode, when using Shift + click to perform range selection
inside an editing `note-edgeless-block` (click at the starting point,
then hold Shift and click at the end point), the block will unexpectedly
lose its editing and selection state. As a result, subsequent operations
on the selection - such as deleting and moving - no longer work.
●The following video demonstrates this issue:
https://github.com/user-attachments/assets/82c68683-e002-4a58-b011-fe59f7fc9f02
### Solution
●The reason is that this "Shift + click" behavior is being handled by
the default multi-selection logic, which toggles selection mode and
exits the editing state. So I added an `else-if` branch to match this
case.
### After
●The video below shows the behavior after this fix.
https://github.com/user-attachments/assets/18d61108-2089-4def-b2dc-ae13fc5ac333
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved selection behavior during note editing in multi-select mode
to provide more intuitive interaction when using range selection during
active editing.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
### Problem
●In edgeless mode, when the `note-edgeless-block` is scaled below 100%,
its outer dimension becomes larger than its content region. This extra
invisible region will block some user interactions such as clicks and
hovers on editing elements underneath.
<img width="1060" height="541" alt="note-elem-block-click"
src="https://github.com/user-attachments/assets/860d7a4f-d159-437b-bbe8-4560e2463e3d"
/>
●The following video demonstrates this issue:
https://github.com/user-attachments/assets/3b719b25-0d7e-496b-9507-6aa65ed0a797
### Solution
●The root cause is that `transform: scale(...)` CSS property (which
implements the scale) is currently applyed to its **inner root element**
instead of itself, and the solution is to move this CSS property to the
proper place.
### After
●The video below shows the behavior after this fix.
https://github.com/user-attachments/assets/e2dbd75d-c2ea-460d-90a1-5cc13e12d5b8
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Centralized CSS scaling for graphics and edgeless note blocks into
dedicated public methods; rendering now uses these methods instead of
inline transform calculations.
* **Tests**
* Updated end-to-end checks to read scale directly from the edgeless
note element and use a more flexible transform-matching pattern.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
### Problem
There's a one-time content-size mismatch during surface-block resize
after a zoom change in edgeless mode, as shown in the image and video
below.
<img width="885" height="359" alt="图片"
src="https://github.com/user-attachments/assets/97a85924-1ca1-4b48-b334-6f19c7c41f49"
/>
https://github.com/user-attachments/assets/1c0e854c-b12e-4edc-9266-6358e0cf9d5a
### Reason and resolve
`Viewport` maintains a `_cachedBoundingClientRect` that stores the
synced-doc-block’s bounding box size. This cache is cleared by a
ResizeObserver on resizing.
In `EmbedSyncedDocBlockComponent`, `fitToContent()` depends on this
cache, and is triggered by another ResizeObserver registered in
`_initEdgelessFitEffect()`.
Since `_initEdgelessFitEffect()` is invoked before the `Viewport`’s
ResizeObserver is registered — dut to `_renderSyncedView()` not being
called for the first-time in `renderBlock()` — `fitToContent()` reads a
stale cached value at the beginning of the resize, resulting in the
one-time content-size mismatch.
This PR ensures that `_initEdgelessFitEffect()` is called after the
registration of the ResizeObserver in `Viewport`.
### After
https://github.com/user-attachments/assets/e95815e2-0575-4108-a366-ea5c00efe482
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved initialization sequence for embedded synced documents to
ensure proper rendering and resize handling, preventing potential issues
with stale data during component setup.
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
### Problem
●In edgeless mode, the embed-edgeless-doc's content does not match the
size of its outer block when zoom ≠ 1.
●The follwing image and video show the issue at zoom = 0.5.
<img width="610" height="193" alt="图片"
src="https://github.com/user-attachments/assets/c50849c6-d55b-4175-9b70-218f69ab976a"
/>
https://github.com/user-attachments/assets/ea7e7cc4-64ae-4747-8124-16c4eea6458e
### Reason and resolve
●The issue occurs because the surface-block canvas uses the container’s
dimensions obtained from getBoundingClientRect(), which are already
affected by the CSS transform. The canvas is then transformed again
together with the container, causing the size mismatch.
●To keep all drawing operations in the surface-block’s original
coordinate space, we apply a reverse transform to the canvas.
### After
https://github.com/user-attachments/assets/6c802b81-d520-44a0-9f01-78d0d60d37b8
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Canvas rendering now properly responds to viewport zoom levels. Visual
scaling is applied dynamically to ensure canvases align correctly with
viewport scaling, providing consistent and accurate rendering during
zoomed interactions while preserving original canvas dimensions.
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This PR updates the appearance of `embed-linked-doc-block` and
`embed-synced-doc-block` to reflect the trashed state of their linked
documents.
Previously, these blocks showed no visual difference whether the linked
document was trashed or not, despite the existing of codes for
deletion-related appearance.
This change ensures that the deletion appearance is properly displayed.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Documents now support trash state tracking for improved deletion
management
* **Bug Fixes**
* Improved synchronization and refresh of embedded documents when
document states change
* Enhanced handling of trashed documents in embedded content
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
congzhou09