Describe the Bug

Mouse-wheel scroll/zoom (ZoomScroll) stops working while the pointer is over HTML that sits on top of the canvas — e.g. an overlay (overlays.add(...)) or an open pad such as the context/append pad.

ZoomScroll binds its wheel listener on canvas.mouseover and unbinds it on canvas.mouseout (ZoomScroll.js), and those events are fired from the canvas SVG element. Overlays and pads are HTML siblings of the SVG under .djs-container, not inside it — moving onto one fires the SVG's mouseout with no matching mouseover, so ZoomScroll unbinds its listener and the wheel no longer pans/zooms the canvas.

This became even more critical with new append pad indicator, which brings more overlays on the canvas.

Steps to Reproduce

1. Open diagram
2. Open any context pad
3. Try to move canvas though the opened pad

Expected Behavior

Wheel scroll/zoom keeps working while the pointer is over overlays and pads (and other HTML that belongs to the canvas surface), the same as over the diagram itself — while still excluding UI that is intentionally not part of the scroll surface.

A possible direction: decide per wheel event whether the target belongs to the canvas scroll surface (SVG + overlays/pads, plus an opt-in marker like a CSS class / data attribute for custom cases), instead of enabling/disabling ZoomScroll on SVG mouseover/mouseout.

As alternative option we can expose the wheel handler. Make ZoomScroll's wheel handling public (e.g. zoomScroll.handleWheel(event) — the current private _handleWheel without the enabled guard). Consumers that put interactive HTML on the canvas can then forward wheel events with a single call:

element.addEventListener('wheel', event => zoomScroll.handleWheel(event));

Environment

Please complete the following information:

• Browser: [e.g. IE 11, Chrome 69]
• OS: [e.g. Windows 7]
• Library version: [e.g. 2.0.0]