Files
hyperframes/packages/studio/src/components/editor/domEditInlineTextElement.test.ts
T
Miguel Ángel 4cc46f5f9f feat(studio): edit and style text in the preview (#3143)
* feat(studio): edit and style text in the preview

Double-press a text element in the canvas and the caret opens where you
pressed, in the element itself rather than in a panel. Select characters and
a small toolbar offers colour, bold, italic and underline, applied to
exactly those characters.

The toolbar lives in Studio's document rather than the composition's.
Putting it in the preview would inject Studio's chrome into the user's
composition, where a render would capture it and the composition's own
styling would inherit into it.

In a flex or grid container the rebuilt runs go inside one wrapper, so a
coloured word cannot reflow the element it sits in.

Also fixes the keyboard: the shortcut guards matched contenteditable=true
only, so playback shortcuts ate letters typed into the composition.

* refactor(studio): keep domEditingLayers under the size cap

The rich-text operation pushed this file past the 600-line gate. Same change
the branch made later, landed with the commit that caused it.

* test(studio): wrap selection changes in act

* fix(studio): restore rich text after failed save

* fix(studio): polish inline text editing

* fix(studio): harden inline text editing
2026-08-11 03:54:18 -04:00

60 lines
2.2 KiB
TypeScript

// @vitest-environment happy-dom
import { afterEach, describe, expect, it } from "vitest";
import { canEditElementTextInline } from "./domEditInlineText";
afterEach(() => {
document.body.innerHTML = "";
});
function mount(html: string): HTMLElement {
document.body.innerHTML = html;
return document.body.firstElementChild as HTMLElement;
}
describe("canEditElementTextInline", () => {
it("opens a plain piece of copy", () => {
expect(canEditElementTextInline(mount("<h1>hello world</h1>"))).toBe(true);
});
// The trap this exists for: styling a run of characters puts a span inside
// the element, and a rule of "no element children" would have let the editor
// lock every element it had ever styled out of itself, permanently.
it("still opens an element that has been styled", () => {
const element = mount('<h1>hell<span style="color: red">o</span> world</h1>');
expect(canEditElementTextInline(element)).toBe(true);
});
it("opens an element whose formatting is nested", () => {
const element = mount('<h1><b><span style="color: red">deep</span></b></h1>');
expect(canEditElementTextInline(element)).toBe(true);
});
it("keeps out an element with a structural child, which the panel edits field by field", () => {
expect(canEditElementTextInline(mount("<div><h1>a</h1><p>b</p></div>"))).toBe(false);
});
it("keeps out an element hiding something structural inside its formatting", () => {
expect(canEditElementTextInline(mount("<h1><span><div>a</div></span></h1>"))).toBe(false);
});
it("keeps out the document itself", () => {
expect(canEditElementTextInline(document.body)).toBe(false);
expect(canEditElementTextInline(document.documentElement)).toBe(false);
});
it("keeps out an element that is already being edited", () => {
const element = mount("<h1>hello</h1>");
element.setAttribute("contenteditable", "true");
expect(canEditElementTextInline(element)).toBe(false);
});
it("keeps out an element with no words in it", () => {
expect(canEditElementTextInline(mount("<h1> </h1>"))).toBe(false);
});
it("keeps out nothing at all", () => {
expect(canEditElementTextInline(null)).toBe(false);
});
});