Table handles overlap editor content area in v0.48.0 — likely caused by floating UI portaling to document.body (#2591)

What’s broken?

After upgrading to v0.48.0, the table handles (row drag handle ⋮⋮ on the left, column drag handle ⋮⋮⋮ on top) are mispositioned and overlap the editor's content area:

The row drag handle (⋮⋮) intrudes into the editor's text area, sitting on top of the previous block
The column drag handle (⋮⋮⋮) appears above the table in a way that overlaps surrounding blocks
The horizontal scrollbar of the table renders inside the editor container instead of at the bottom of the table
The AI/floating-action button appears overlapped on top of the table

This is reproducible on the official demo site itself (https://www.blocknotejs.org/demo) without any custom styling, which rules out userland CSS migration as the cause.

What did you expect to happen?

Table handles should be positioned at the edges of the table without overlapping other blocks or floating UI, as they did in v0.47.x.

Steps to reproduce

Open https://www.blocknotejs.org/demo
Click on any cell inside the default table block
Observe that the row/column drag handles overlap surrounding blocks and floating UI

BlockNote version

v0.48.0, v4.48.1, v0.49.0

Environment

No response

Additional context

Suspected root cause

I believe this regression is caused by #2591 ("portal floating UI elements to document.body to prevent overflow clipping") in v0.48.0.

Hypothesis:

Before v0.48.0, table handles were rendered inside .bn-container, sharing the same coordinate space as the table cells. Position calculations worked relative to the editor.
In v0.48.0, floating UI elements — including table handles — are now portaled to document.body. This changes the reference frame to the viewport.
The table handle positioning logic appears to still compute offsets relative to the editor's internal coordinate system, or fails to account for the new portal target's scroll/transform context. As a result, handles render at the wrong absolute position and overlap editor content.

If table handles were not intentionally included in the portaling change, scoping the portal behavior to only menus/toolbars (and keeping table handles inside .bn-container as before) could be a quick fix. Otherwise the position calculation needs to be updated for the portaled context.

The related breaking change in v0.48.0 also splits .bn-container (editor only) from .bn-root (editor + floating UI), which seems consistent with this portaling change.

Contribution

I'd be interested in contributing a fix for this issue

Sponsor

I'm a sponsor and would appreciate if you could look into this sooner than later 💖

This has been how it has been styled for a while. I checked a build that was Dec 15, 2025: https://blocknote-git-quote-isolating-typecell.vercel.app/ui-components/advanced-tables and it is styled the same. What is the issue with this? How is this intruding?
If you want to change it, I'm sure you can target this with CSS

As for the portaling, right now it cannot be configured, but I'd consider a second parameter to mount to allow configuration of where the portalElement should mount to:

BlockNote/packages/core/src/editor/BlockNoteEditor.ts

Lines 736 to 742 in a5ff04d

    
           public mount = (element: HTMLElement) => { 
        
             const root = element.getRootNode(); 
        
             if (typeof ShadowRoot !== "undefined" && root instanceof ShadowRoot) { 
        
               root.appendChild(this.portalElement); 
        
             } else { 
        
               document.body.appendChild(this.portalElement); 
        
             }

If this is is of interest to you, feel free to submit a PR for it

Hi,
I'm a product planner at the same company as the original reporter of this issue. While reviewing the closed status together, we felt there were a few additional points worth raising, so I'd like to share them here.

1. Prior occurrence does not make it acceptable behavior.
We acknowledge that this may have existed in earlier versions as well. However, we had already considered it abnormal behavior at the time — we simply hadn't filed a separate issue for it. The fact that a problem has been present for a while does not mean it is intended or acceptable. Whether it is a long-standing issue or a recent regression, it remains a defect that we believe needs to be addressed.

2. This cannot be fixed with CSS.
The misalignment of table handles stems from a coordinate reference mismatch — handles are now rendered in the document.body context while their positions are still calculated relative to the editor container. This is a logic-level issue, not a styling issue. CSS overrides cannot correct a fundamentally broken position calculation.

3. Floating UI is being obscured by or conflicting with host app UI.
In environments where the editor is embedded within complex layouts — such as fixed headers, sidebars, drawers, or modals — portaling all floating UI to document.body causes z-index conflicts. As a result, slash menus, formatting toolbars, and table handle menus either get hidden behind unrelated UI elements or render on top of them unexpectedly. It is not reasonable to ask integrators to restructure their entire app's z-index system to work around this behavior.

4. Table handles rendering outside the editor boundary is not acceptable UX.
The editor is embedded as a component within a larger product. When table handles escape the editor's container and appear in surrounding page areas, it breaks the editor's integrity as a self-contained component. From a product perspective, this creates unnecessary visual noise and confusion for end users — and again, this is not something that can be addressed through CSS alone.

5. Per-element portal configuration would be the right solution.
Rather than applying a single portal target uniformly across all floating UI, we'd like to suggest making the portal target configurable per element type. For example, a structure like the following would allow integrators to scope each UI element appropriately depending on their environment:

const floatingUIOptions = {
  portalMapping: {
    tableHandles: "bn-container", // keep within editor boundary
    dropMenus: "body",            // prevent overflow clipping
    tooltips: "body"
  }
}

6. The "Add Row" button should remain within the visible editor area.
Currently, the add row button inherits the full width of the table, which causes it to move outside the user's visible screen area as the table grows wider horizontally. We believe the button's width should be constrained to the actual available width of the editor viewport (excluding padding), rather than the full table width. This would ensure that the add row button remains accessible within the visible editor area regardless of how wide the table extends.

We hope this issue can be reconsidered as an open bug. We're happy to provide additional reproduction cases or environment details if that would be helpful. Thank you for your time.

@Dahye-Yeom

Hi @Dahye-Yeom,

Thanks for bringing this up, I missed the second screenshot, which I agree is definitely an issue. I guess what I missed is that the issue was talking about the table handles, and I really don't see an issue with how the table handles look in either of those screenshots? But, I should have reviewed further.

Per-element portal configuration would be the right solution.
Rather than applying a single portal target uniformly across all floating UI, we'd like to suggest making the portal target configurable per element type.

What would this enable that a single target element would not achieve?
If you want your UI elements to stay contained within an element, wouldn't you want that to be one element instead of having to configure that individually?

1,2,3,4,6 are all resolved by being able to target the element that floating ui is portaled to as I suggested here: #2692 (comment) am I missing something?

Thank you for the response. We agree that a single configurable portal target would resolve many of the cases we raised. However, we'd like to explain why per-element configuration is still necessary for our use case.

In our product, the editor is used across both small and large areas — for example, a compact inline editor in some views, and a full-page editor in others. This means a one-size-fits-all portal target doesn't work well for us.

When the editor is embedded in a smaller area, portaling all floating UI to the editor container causes larger UI elements like the slash menu or color picker to get clipped by the editor's boundaries and not display properly. These elements need to be portaled to body to render fully.

On the other hand, elements like table handles need to stay scoped within the editor container — otherwise they escape the editor boundary, which is the core issue we've been describing.

In other words, forcing all floating UI to a single portal target will inevitably cause problems on one side or the other, depending on the editor's size and layout context. Per-element portal configuration is the only way to satisfy both cases simultaneously.

We'd really appreciate this being considered as part of the fix. Thank you for your continued engagement on this.

feat(react): configurable portal targets for floating UI (TypeCellOS#…

fix(shared-notes): clamp BlockNote table add-row/column handles insid…

Navigation Menu

Repository navigation

Table handles overlap editor content area in v0.48.0 — likely caused by floating UI portaling to document.body (#2591) #2692

What’s broken?

What did you expect to happen?

Steps to reproduce

BlockNote version

Environment

Additional context

Suspected root cause

Related question: opt-out for portaling floating UI to `document.body`?

Contribution

Sponsor

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	public mount = (element: HTMLElement) => {
	const root = element.getRootNode();
	if (typeof ShadowRoot !== "undefined" && root instanceof ShadowRoot) {
	root.appendChild(this.portalElement);
	} else {
	document.body.appendChild(this.portalElement);
	}

Table handles overlap editor content area in v0.48.0 — likely caused by floating UI portaling to document.body (#2591) #2692

Description

What’s broken?

What did you expect to happen?

Steps to reproduce

BlockNote version

Environment

Additional context

Suspected root cause

Related question: opt-out for portaling floating UI to document.body?

Contribution

Sponsor

Activity

nperez0111 commented on Apr 30, 2026

nperez0111 commented on Apr 30, 2026

Dahye-Yeom commented on May 8, 2026

nperez0111 commented on May 8, 2026

Dahye-Yeom commented on May 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Related question: opt-out for portaling floating UI to `document.body`?