@zenuml/core 3.47.9 → 3.48.1

package/docs/ux-research/2026-04-15-rename-participant.md

@@ -1,156 +0,0 @@
----
-scenario_id: rename-participant
-scenario_title: Rename a participant via keyboard
-run_date: 2026-04-15
-zenuml_core_sha: 2c6e120d
-audited_url: http://localhost:4000
-skill_version: 0.1.0
-gap_count: { high: 2, med: 1, low: 0 }
----
-
-# UX Research — Rename a participant via keyboard
-
-## Executive summary
-
-Renaming a participant on the ZenUML canvas is not possible without editing the DSL text directly. Clicking a participant opens a style panel (color/type selector) instead of selecting it for editing. Pressing Enter toggles that style panel rather than entering inline edit mode. No inline edit affordance exists for participant labels — the code explicitly treats the participant as a "style" button (`role="button"`, `title="Click to style participant"`). The most important thing to fix is adding an inline edit mode triggered by Enter on a selected participant, separating selection from the style panel.
-
-## Scenario recap
-
-**User intent:** The user has a participant `A` on the canvas and wants to rename it to `Alice` without leaving the keyboard.
-
-**Starting DSL:**
-```
-A
-```
-
-**Target DSL:**
-```
-Alice
-```
-
-## Observed walkthrough
-
-### Path 1 — Click to select, then Enter to edit (most discoverable keyboard path)
-
-1. **Typed `A` in the DSL editor** to seed the starting state. Participant A appeared on the canvas in both DOM and SVG previews. (Setup, not walkthrough.)
-
-2. **Clicked participant A on the canvas.** A style panel opened immediately below the participant showing COLOR swatches and TYPE selectors (Actor, Boundary, Control, Entity, Database, Queue, None). Participant A showed a blue selection ring (`ring-2 ring-sky-400`). The panel opened on click rather than on a secondary gesture — click is conflated with "open panel," not "select for editing."
-
-3. **Pressed Enter.** The style panel closed. The blue selection ring remained on participant A. **No edit mode appeared** — the label `A` remained static text, not an editable input.
-
-4. **Pressed Enter again.** The style panel re-opened. Enter toggles the style panel. The code at `Participant.tsx:114-118` explicitly routes `Enter` to `onSelect()` which opens the style panel. There is no code path from Enter to an inline edit mode.
-
-5. **Pressed Escape.** The style panel closed and selection was cleared (blue ring disappeared). This is correct behavior — Escape dismisses the panel and deselects.
-
-### Path 2 — Double-click to edit
-
-6. **Double-clicked participant A on the canvas.** The style panel opened, identical to single-click. Double-click does not enter edit mode. There is no differentiation between single-click and double-click on the participant component.
-
-### Path 3 — DSL editor fallback
-
-7. The only way to rename participant A to Alice is to edit the DSL directly: click into the code editor, select `A`, type `Alice`. This works but requires leaving the canvas entirely and switching to the text editor pane.
-
-## Gaps
-
-### Gap 1 — Enter on selected participant toggles style panel instead of entering edit mode
-**Severity:** high
-**Catalog ID:** KBD-03 (Enter enters edit mode on selected item)
-**Observed:** After clicking participant A (which opens the style panel) and pressing Escape to close the panel, pressing Enter re-opens the style panel. The cycle repeats: Enter and Escape toggle the panel. No edit mode is ever entered.
-**Expected:** Pressing Enter on a selected participant should replace the label with a focused, editable input so the user can retype the name. The style panel should be accessed via a secondary gesture (e.g., right-click or a dedicated button), not via the same interaction as editing.
-**Exemplars:** Figma (Enter on selected text layer enters edit mode), Notion (Enter on selected cell enters edit mode), tldraw (Enter on selected shape enters text edit), VS Code (F2 on selected item enters rename mode).
-**Rationale:** The Enter key is the universal "act on this selection" key in canvas editors. Using it for the style panel instead of inline editing forces users to leave the canvas for what should be the most common operation — renaming.
-**Suggested fix:** `src/components/DiagramFrame/SeqDiagram/LifeLineLayer/Participant.tsx:114-118` — the `onKeyDown` handler currently routes `Enter` to `onSelect()` (which opens the style panel). This handler should be changed so that Enter triggers an inline edit mode instead. The `onSelect` / style-panel behavior should move to a secondary gesture. No existing edit-mode handler was found — this is a missing code path, not a misrouted one. The concurrent `keyboard-editing-on-diagram` design spec (`docs/superpowers/specs/2026-04-15-keyboard-editing-on-diagram-design.md`) appears to address exactly this gap.
-
-### Gap 2 — No inline edit mode exists for participant labels
-**Severity:** high
-**Catalog ID:** EDT-01 (entering edit mode replaces the label with a focused, editable input)
-**Observed:** The participant component renders the label as a static `<div>` inside a flex container. There is no code path that transforms this into an editable input, contenteditable span, or any form of inline editing. The `role="button"` and `title="Click to style participant"` attributes on the participant div confirm this is intentionally a style-trigger, not an edit target.
-**Expected:** When edit mode is triggered (by Enter, double-click, or F2), the static label should be replaced by an editable input at the same visual position, with focus and cursor placement at end-of-text.
-**Exemplars:** Figma (text layers become editable on Enter), tldraw (shapes show text input on Enter), Notion (cells become editable inputs on Enter).
-**Rationale:** Inline editing is the single most expected interaction on a canvas item after selection. Its absence forces all renaming through the DSL editor, breaking the user's flow between "I see the diagram" and "I edit the diagram."
-**Suggested fix:** `src/components/DiagramFrame/SeqDiagram/LifeLineLayer/Participant.tsx` — no edit-mode logic exists in this file. A new state (`isEditing`) and a conditional render path are needed: when `isEditing` is true, render an `<input>` or `<EditableSpan>` (an existing component at `src/components/common/EditableSpan/EditableSpan.tsx`) in place of the static label. Note: `EditableSpan` already exists in the codebase and has keyboard handling — it may be reusable here.
-
-### Gap 3 — Click conflates selection with opening the style panel
-**Severity:** med
-**Catalog ID:** novel — candidate for new rule (SEL category: "single click selects without opening secondary panels")
-**Observed:** Clicking participant A simultaneously selects it (blue ring) AND opens the style panel. There is no state where the participant is "selected but no panel is open" that is reachable via mouse click alone. The only way to reach a "selected, no panel" state is to click (panel opens) then press Escape (panel closes, but selection clears too per `ParticipantStylePanel.tsx:103-104`).
-**Expected:** Single click should select the participant with a visible selection indicator. The style panel should open on a secondary gesture: either Enter (but we'd want Enter for edit mode), right-click, or a dedicated "style" button/icon on the selection frame. Selection and style-editing should be separate states.
-**Exemplars:** Figma (click selects; panel is opened via sidebar or right-click), tldraw (click selects; style panel is in a persistent sidebar), draw.io (click selects; style is in a panel that opens on secondary action).
-**Rationale:** Conflating selection with panel-opening means the user can never "just select" a participant to then decide what to do with it (rename, delete, move, style). Every click forces the style panel into view, which is the wrong action most of the time.
-**Suggested fix:** `src/components/DiagramFrame/SeqDiagram/LifeLineLayer/Participant.tsx:113` — the `onClick` handler should set selection state WITHOUT opening the style panel. The style panel trigger should move to a different gesture.
-
-## Coverage
-
-Tested hypotheses (no gap found):
-- KBD-05: Escape on the style panel correctly closes it (verified in `ParticipantStylePanel.tsx:101-105`)
-- SEL-03: Selection indicator (blue ring) IS implemented via `ring-2 ring-sky-400` CSS class (verified at `Participant.tsx:102`)
-- Participant IS keyboard-focusable via `tabIndex={0}` (verified at `Participant.tsx:120`)
-- KBD-04: Escape during edit mode cancels — not testable because edit mode does not exist
-
-Not tested (out of scope for this scenario):
-- INS, UND, FBK categories
-- Arrow-key navigation between participants (this scenario focuses on a single participant)
-
-Skipped (couldn't form a testable hypothesis):
-- KBD-01: Tab into the diagram widget — the Dev Workbench layout (editor + two previews) makes tab-order analysis unreliable in this context; would need a standalone embed to test properly
-
-## Best-practice sources
-
-**Bundled catalog IDs referenced:**
-- KBD-03 (Enter enters edit mode)
-- KBD-04 (Escape cancels edit)
-- KBD-05 (Escape on selected item deselects or exits)
-- EDT-01 (inline edit replaces label with input)
-- EDT-02 (caret at end of text)
-- SEL-01 (click selects exclusively)
-- SEL-03 (visible selection indicator)
-
-**Web sources fetched during this run:**
-- None needed — catalog coverage was sufficient for this scenario.
-
-## Playwright regression snippet
-
-Paste into `zenuml-core/tests/ux/rename-participant.spec.ts` once the gaps are fixed. The skill emits this snippet; it does not run it.
-
-```typescript
-import { test, expect } from "@playwright/test";
-
-test("KBD-03: Enter on selected participant enters edit mode", async ({ page }) => {
-  await page.goto("/");
-  // Clear and seed DSL with a single participant
-  await page.click("text=Clear");
-  await page.locator(".cm-content").click();
-  await page.keyboard.type("A");
-  // Wait for participant to render
-  await page.waitForSelector('[data-participant-id="A"]');
-  // Click participant to select it
-  await page.click('[data-participant-id="A"]');
-  // Close the style panel if it opens
-  await page.keyboard.press("Escape");
-  // Now press Enter — should enter edit mode
-  await page.click('[data-participant-id="A"]');
-  await page.keyboard.press("Enter");
-  // Verify an editable input appeared
-  const input = page.locator('[data-participant-id="A"] input, [data-participant-id="A"] [contenteditable]');
-  await expect(input).toBeFocused({ timeout: 500 });
-});
-
-test("EDT-01: Edit mode shows editable input at label position", async ({ page }) => {
-  await page.goto("/");
-  await page.click("text=Clear");
-  await page.locator(".cm-content").click();
-  await page.keyboard.type("A");
-  await page.waitForSelector('[data-participant-id="A"]');
-  // Enter edit mode (once implemented)
-  await page.click('[data-participant-id="A"]');
-  await page.keyboard.press("Enter");
-  const input = page.locator('[data-participant-id="A"] input, [data-participant-id="A"] [contenteditable]');
-  await expect(input).toBeVisible();
-  // Type new name and commit
-  await input.fill("Alice");
-  await page.keyboard.press("Enter");
-  // Verify DSL updated
-  const editor = page.locator(".cm-content");
-  await expect(editor).toContainText("Alice");
-});
-```

package/docs/ux-research/2026-04-18-insert-participant.md

@@ -1,151 +0,0 @@
----
-scenario_id: insert-participant
-scenario_title: Insert a participant on a blank diagram
-run_date: 2026-04-18
-zenuml_core_sha: e8db2a7a
-audited_url: http://localhost:4000
-skill_version: 0.1.0
-gap_count: { high: 3, med: 1, low: 0 }
----
-
-# UX Research — Insert a participant on a blank diagram
-
-## Executive summary
-
-Inserting a participant on a blank ZenUML canvas requires editing the DSL text directly — there is no canvas-based insertion affordance. Clicking the canvas background, double-clicking, right-clicking, and pressing Enter or other keys on the canvas all produce no response. The diagram container has no `tabindex`, `role`, or ARIA attributes, so it cannot receive keyboard focus at all. The only working path is clicking into the DSL editor pane and typing the participant name. While this works, it means ZenUML's canvas is purely a rendering surface with no creation capabilities — a significant gap for new users who expect a diagramming tool to let them create directly on the canvas.
-
-## Scenario recap
-
-**User intent:** The user opens ZenUML to a blank diagram and wants to add one participant named `Alice` so they can start modelling.
-
-**Starting DSL:**
-```
-```
-
-**Target DSL:**
-```
-Alice
-```
-
-## Observed walkthrough
-
-1. **Cleared editor** — clicked "Clear" button to reach blank-diagram state. Canvas shows a single anonymous participant (person icon) with no label.
-2. **Clicked canvas background** (empty area to the right of the default participant) — no visible change, no context menu, no insertion affordance.
-3. **Searched for "Add participant" or "+" button** using accessibility tree scan — no matching elements found. Bottom toolbar contains only info, emoji/settings, version badge, zoom controls, and ZenUML.com link.
-4. **Pressed Enter on canvas** — no response. Canvas does not appear to receive keyboard focus.
-5. **Right-clicked canvas background** — no custom context menu appeared (browser default was suppressed but nothing replaced it).
-6. **Double-clicked canvas background** — no response.
-7. **Fell back to DSL editor** — clicked into the code editor pane on the left, typed `Alice`. Canvas immediately rendered a participant labeled "Alice". Target state reached.
-
-## Gaps
-
-### Gap 1 — No canvas-based insertion affordance for participants
-
-**Severity:** high
-**Catalog ID:** INS-01
-**Observed:** The only way to insert a participant is by typing directly into the DSL editor pane. No button, context menu, toolbar item, or click gesture on the canvas creates a new participant.
-**Expected:** At least one insertion path that does not require opening or touching the DSL editor directly (e.g., a visible "+" button, a right-click context menu, or clicking empty canvas space to create a participant).
-**Exemplars:** tldraw (visible toolbar with shape tools), Figma (toolbar + keyboard shortcuts), Miro (visible "+" for stickies), draw.io (drag from shape palette).
-**Rationale:** For a tool growing canvas affordances, the canvas should be a primary creation surface. Being forced into the DSL editor to create the most basic element is a high-friction barrier for new users.
-**Suggested fix:** No code path found — this is a missing implementation, not a misrouted one. The canvas (`src/components/DiagramFrame/SeqDiagram/`) has no insertion handlers. Participant creation is exclusively driven by DSL parsing in `src/parser/ToCollector.js` and `src/parser/Participants.ts:110` (`Add` method).
-
-### Gap 2 — No keyboard-only insertion path
-
-**Severity:** high
-**Catalog ID:** INS-03
-**Observed:** Pressing Enter, Tab, or letter keys while the canvas area has apparent focus produces no effect. There is no keyboard shortcut to insert a participant.
-**Expected:** At least one keyboard-only path from blank state to new participant (e.g., pressing `p` to create a participant, or Tab into the canvas then Enter to create).
-**Exemplars:** Miro (Tab from one sticky creates a sibling), Linear (Cmd+Enter for new issue), Notion (Enter in a database for a new row).
-**Rationale:** ZenUML's user base is text-first and keyboard-native. A mouse-only workflow (click into DSL editor) is acceptable but a keyboard shortcut for the most common creation action would match user expectations.
-**Suggested fix:** No keyboard event handlers exist on the diagram container (`src/components/DiagramFrame/SeqDiagram/SeqDiagram.tsx`). The container div has no `tabindex` attribute, so it cannot receive focus or keyboard events. Only `src/components/common/EditableSpan/EditableSpan.tsx:111` and `src/components/DiagramFrame/Debug/index.tsx:8` have keydown handlers.
-
-### Gap 3 — Diagram container is not a focusable widget
-
-**Severity:** high
-**Catalog ID:** KBD-01
-**Observed:** The diagram container (`div.zenuml.sequence-diagram`) has no `role`, no `tabindex`, and no `aria-label`. It cannot receive keyboard focus via Tab. Pressing Tab from the editor pane skips over the diagram entirely.
-**Expected:** The diagram should be one Tab stop from the page's perspective (the ARIA composite-widget convention). Tab moves focus into the diagram; Shift+Tab moves focus out.
-**Exemplars:** Figma canvas (focusable, receives keyboard events), VS Code tree view (composite widget with `role="tree"` and `tabindex`).
-**Rationale:** Without being focusable, the diagram cannot support any keyboard interaction — selection, navigation, editing, or insertion. This is the foundational gap that blocks KBD-02 through KBD-06.
-**Suggested fix:** The diagram container is rendered in `src/components/DiagramFrame/SeqDiagram/SeqDiagram.tsx`. It needs `tabIndex={0}`, `role="application"` or `role="group"`, and `aria-label="Sequence diagram"`. No such attributes exist anywhere in the component tree — grep for `tabindex` and `role=` across `src/components/` returned zero matches.
-
-### Gap 4 — Insertion affordance not discoverable within 10 seconds
-
-**Severity:** med
-**Catalog ID:** INS-02
-**Observed:** On a blank canvas, a new user sees a single anonymous participant icon and an empty area. No visual cue suggests how to create a new participant. The DSL editor on the left has a dark background with just a line number "1" — it does not prompt or hint that typing there creates participants. Discovery required switching mental models from "canvas tool" to "text editor" and realizing the left pane is the creation mechanism.
-**Expected:** The primary insertion affordance should be discoverable by a new user within ~10 seconds of looking at the canvas (e.g., a visible "Add participant" button, a "+" icon, or placeholder text like "Type a participant name here").
-**Exemplars:** tldraw (visible toolbar with labeled shape tools), Figma (prominent toolbar), draw.io (shape palette on the left).
-**Rationale:** Discoverability is the gateway to every other interaction. Hidden affordances turn new users away.
-**Suggested fix:** The blank-canvas state is rendered by `src/components/DiagramFrame/SeqDiagram/SeqDiagram.tsx` and `src/components/DiagramFrame/SeqDiagram/LifeLineLayer/`. No empty-state guidance, placeholder text, or onboarding affordance exists. A `TipsDialog` component exists at `src/components/DiagramFrame/Tutorial/TipsDialog.tsx` but it is a general tips dialog, not contextual insertion guidance.
-
-## Coverage
-
-Tested hypotheses (no gap found):
-- DSL editor correctly creates a participant when text is typed (verified — `Alice` appeared immediately on canvas)
-- No console errors during walkthrough (verified — only debug-level render messages)
-
-Not tested (out of scope for this scenario):
-- EDT-02 (caret placement on edit entry — tested in rename-participant scenario)
-- EDT-04 (commit/cancel contract — tested in rename-participant scenario)
-- KBD-04, KBD-05 (Escape behavior — requires selection, which requires focus, which is blocked by Gap 3)
-- UND-01, UND-02, UND-03 (undo/redo — tested in undo-insert scenario)
-
-Skipped (couldn't form a testable hypothesis):
-- FOC-01 (focus after keyboard insertion — no keyboard insertion path exists, so this is untestable; subsumed by Gap 2)
-- KBD-02 (arrow-key navigation — diagram not focusable; subsumed by Gap 3)
-- KBD-06 (Tab to spawn sibling — diagram not focusable; subsumed by Gap 3)
-
-## Best-practice sources
-
-**Bundled catalog IDs referenced:**
-INS-01, INS-02, INS-03, KBD-01, FOC-01, EDT-03
-
-**Web sources fetched during this run:**
-None — catalog and common sense were sufficient for this scenario.
-
-## Playwright regression snippet
-
-Paste into `zenuml-core/tests/ux/insert-participant.spec.ts` once the gap is fixed. The skill emits this snippet; it does not run it.
-
-```typescript
-import { test, expect } from "@playwright/test";
-
-test.describe("insert-participant UX", () => {
-  test.beforeEach(async ({ page }) => {
-    await page.goto("http://localhost:4000");
-    // Clear to blank state
-    await page.getByRole("button", { name: "Clear" }).click();
-  });
-
-  test("diagram container is focusable via Tab", async ({ page }) => {
-    // Gap 3: KBD-01
-    const diagram = page.locator(".sequence-diagram");
-    await expect(diagram).toHaveAttribute("tabindex", "0");
-    await page.keyboard.press("Tab");
-    // After enough Tabs, focus should land on the diagram
-    await expect(diagram).toBeFocused();
-  });
-
-  test("canvas has a visible insertion affordance", async ({ page }) => {
-    // Gap 1: INS-01 + Gap 4: INS-02
-    // Look for a button or affordance that creates a participant
-    const addButton = page.getByRole("button", { name: /add|insert|new|participant|\+/i });
-    await expect(addButton).toBeVisible();
-  });
-
-  test("keyboard shortcut inserts a participant", async ({ page }) => {
-    // Gap 2: INS-03
-    const diagram = page.locator(".sequence-diagram");
-    await diagram.focus();
-    // Press the expected shortcut (adjust once implemented)
-    await page.keyboard.press("p");
-    // A new participant should appear in edit mode
-    const editInput = diagram.locator("input, [contenteditable=true]");
-    await expect(editInput).toBeFocused();
-    await page.keyboard.type("Alice");
-    await page.keyboard.press("Enter");
-    await expect(diagram.locator(".participant")).toContainText("Alice");
-  });
-});
-```

package/docs/width-translate-and-offsets.md

@@ -1,62 +0,0 @@
-# Interaction width
-
-Interaction width, in the most simple scenario, is defined by the distance of two participants -
-`from` and `to`.
-
-## Simple case
-
-### Width
-
-In the following
-Each '◻' is a pixel
-
-```
-  |   A   |       |   B   |
-1 2 3 4 5 6 7 8 9 a b c d e f g h
-◻ ◻ ◻ ◻ ◻ ◻ ◻ ◻ ◻ ◻ ◻ ◻ ◻ ◻ ◻ ◻ ◻
-```
-
-#### 1. Interaction width
-
-Interaction will overlap the left lifeline but not the right.
-A has left as 2, center as 4 and right as 6; B has a/c/e. For Interaction `m2` in (A.m1{B.m2}),
-the width should be 4 to c (inclusive) that is 9 (`c - 4 + 1`). This is `distance(from, to)`.
-
-#### 2. Message width
-
-Message width should be 100% content + interactionBorderWidthx2 - ((OccurrenceWidth - 1)/2)x2 - interactionBorderWidth.
-
-### Left
-
-#### 1. Message left
-
-```
-100% // content width of interaction
-+ InteractionBorderWidth x 2
-- ((OccurrenceWidth-1)/2) x 2
-```
-
-#### 2. Self Occurrence Left
-
-```
-left: width of InteractionBorderWidth
-```
-
-### Offset
-
-There are a few ways to implement offset, we have to combine them.
-
-#### 1. Padding of occurance
-
-> Suppose the width of an occurance is 5 (border width 1x2, content 3)
-
-To aligh Occurance's center, we need to set its left. An occurance
-at `left: 100%` will be from c to g. Note that the 100% only consider
-the content width.
-
-To align its center to c, we
-have to move back by 3 (`(occuranceWidth-1)/2 - interactionBorderWidth - LifelineWidth`).
-
-occurance must have a padding of 1 that is (width - boarder x 2 - 1) / 2.
-
-## Self call indent

package/docs/xss.md

@@ -1,59 +0,0 @@
-In this document we are disclosing a cross-site scripting vulnerability in the
-[@zenuml/core](https://www.npmjs.com/package/@zenuml/core) package.
-XSS is a type of security vulnerability that allows an attacker to inject
-malicious code into a web page viewed by other users.
-
-# How to reproduce
-
-ZenUML generates sequence diagrams from text. If the text contains a
-malicious script, it will be executed when the diagram is rendered.
-
-The following content is known to pop an alert box:
-
-```
-"><img src=x onerror=alert(1)>ent #FFEBE6
-```
-
-# Known affected products
-
-| Product           | Severity | Comment                                                             |
-|-------------------|----------|---------------------------------------------------------------------|
-| Confluence plugin | P3       | Content must be create by registered users; scripts run in sandbox. |
-| Web App           | P3       | Only the current user can view content created by themselves.       |
-| Chrome Extension  | P3       | Only the current user can view content created by themselves.       |
-| Desktop (Win/Mac) | P3       | Only the current user can view content created by themselves.       |
-| JetBrains plugin  | P3       | Scripts run inside sandbox.                                         |
-
-# What is the cause of the vulnerability?
-
-The cause of the XSS vulnerability in @zenuml/core is due to accepting an arbitrary text as `innerHTML` in the
-WidthProviderFunc.ts file. Specifically, the vulnerability is located in the code that measures the width 
-of the message or participant element in the library. The issue is present in line 29 of the file, which 
-can be found at [this URL](https://github.com/ZenUml/core/blob/577f2a550a0b82a392215875298bc358a8feff0d/src/positioning/WidthProviderFunc.ts#L29). 
-In this line, the code uses unsanitized user input which is passed as an argument in the function, this 
-allows an attacker to inject malicious JavaScript code into the web page viewed potentially by other users.
-
-```
-  let hiddenDiv = document.querySelector('.textarea-hidden-div') as HTMLDivElement;
-  if (!hiddenDiv) {
-    const newDiv = document.createElement('div');
-    ...
-    document.body.appendChild(newDiv);
-    hiddenDiv = newDiv;
-  }
-  hiddenDiv.innerHTML = text;
-  const scrollWidth = hiddenDiv.scrollWidth;
-  return scrollWidth;
-```
-
-# Fix of the vulnerability
-
-The fix is to replace the `innerHTML` with `textContent` in the code. This will prevent the browser from
-interpreting the text as HTML and will treat it as plain text.
-
-```
-  ...
-  hiddenDiv.textContent = text;
-  const scrollWidth = hiddenDiv.scrollWidth;
-  return scrollWidth;
-```