Vaadin Dialog overlay retention causing client‑side memory growth

Direct answer

Under normal Vaadin 14 cleanup, the Dialog overlay is designed to be detached from the DOM and have its internal event listeners removed when close() completes. A lasting overlay-to-dialog reference is therefore not expected after closure. However, this is not a blanket guarantee that every application-owned object becomes unreachable.

Repeated open/close cycles can show retained-memory growth in Chrome, particularly when custom content installs listeners or closures, or when the dialog remains attached or reachable elsewhere. The symptom alone does not establish a Vaadin leak, and reproducibility must be measured in the affected release and browser.

What the lifecycle establishes

• Closing and disposing are different. close() ends the overlay interaction; it does not promise to dispose arbitrary custom components or remove application-installed listeners.
• A vaadin-dialog entry remaining in a heap snapshot is not proof of a leak. The relevant evidence is increasing retained size plus a retainer path showing that the closed overlay or dialog remains reachable.
• Results from Vaadin 14 and Chrome should not be generalized to newer Vaadin releases or other browsers without separate testing.

Focused verification

1. Record the exact Vaadin 14 patch release and Chrome version. Start with plain content and no custom frontend integration.
2. Run twenty cycles from a button action:

Dialog dialog = new Dialog();
dialog.setContent(new Span("probe"));

Button run = new Button("Run", event -> {
    for (int i = 0; i < 20; i++) {
        dialog.open();
        dialog.close();
    }
});

1. Take a baseline heap snapshot after using Chrome DevTools' garbage-collection control. Run the cycles, collect garbage again, and take a second snapshot. Compare retained size and retainer paths for dialog- and overlay-related nodes rather than relying only on object counts.
2. Inspect the Event listeners view for listeners attached to detached dialog or overlay elements. If growth appears only after custom content is added, isolate that content and remove its listeners before closing.
3. Repeat with a fresh dialog instance per iteration and reload the page between experiments. Reloading between every iteration would erase the accumulation being measured.

Interpreting the result

• If plain content grows monotonically and the retainer path runs from overlay state to the closed dialog, document it as a Vaadin 14 retention issue with exact versions and snapshots.
• If growth tracks custom components or listeners, correct application cleanup: detach custom content, unregister listeners, remove the dialog from its parent if attached, and release application-held client-side references.
• If retained size stabilizes after garbage collection, the earlier increase may have been uncollected garbage or normal framework and browser caches rather than a leak.

The one diagnostic detail that changes the recommendation is whether the reproduction contains only plain Label or Span content, or custom components and client-side listeners.