Panning in Firefox broken in Shadow DOM?

[Chris-SP365]

Hi,

Firefox can't pan the image while moving the mouse pointer inside the image area. If I grab the image and move the mouse out of the area then I can pan the image.

I use OSD inside a shadow dom element. Maybe that's the problem? Are there any recommendations about using OSD in a shadow dom environment?

Chromium-Edge and Chromium work fine btw.

Thank you

[iangilman]

That certainly could be! Panning works fine in Firefox normally.

Do you have a link you can share?

We have a couple of other issues related to Shadow DOM, I'm not sure if either are relevant: #1674, #1677

[Chris-SP365]

Unfortunately I couldn't reproduce it in a shadow dom SSCCE. Maybe Vaadin or other things are the reason for the problem. I tried various things:

1. Problem occurs only in Firefox.
2. I looked at the way the events are called. It seems that in most drag events, lastPos and currentPos seem to be equal if I move the mouse inside the image area.
3. It looks like an additional onPointerOver is called (Firefox config dom.w3c_pointer_events.enabled is true)
4. I don't know why pointerover is called. At least I can't reproduce it in a shadow dom.
5. I guess by calling onPointerOver the lastPos is updated which then leads to a 0,0 delta

Maybe that information is useful. I can't really think of a way to track it down further since pointer events are browser native things.

[iangilman]

Interesting. Have you tried it on different devices/OSs? Is the device you're on one that utilizes pointer events?

Can you make a cut down repro you can share? That might shed some light…

[Chris-SP365]

It's a non touch dell laptop with Windows 10, but a "Debian 10 w. Firefox inside VirtualBox" behaves exactly this way (though I didn't really look at the events).

I'll try to get an example for you tomorrow.

[Chris-SP365]

https://webapps.inputsys.de/test

• Open Firefox
• Open the console
• Zoom in
• Pan the image

If you pan inside the image, every time a updatePointersMove is called, also updatePointersEnter is called, because an onPointerOver happens.

If you move the mouse pointer outside of the image while panning, it seems ok because only one updatePointersMove is called (and delta is calculated right).

[msalsbery]

Sounds like event handlers in capture phase don’t work in shadow DOM. The pointerdown gets handled so start point is known for computing deltas, but then pointermove events are switched to a handler on the capture phase, aren’t picked up due to shadow DOM use, but are picked up then pointer moves to regular DOM element.

We use capture phase for drag gesture handling due to browser differences in pointer capture API support.

Clearly, from my comments above, I know next to nothing about shadow DOM, and about event handling implications, but I’m reworking MouseTracker and intend to remove the capture phase hack which may solve this. A few days I’ll have something testable...

[Chris-SP365]

Sounds promising. I'll be happy to test.
Thank you

[msalsbery]

Gracias Ian :)

[Chris-SP365]

If there is anything I can help to get the issue solved please feel free to contact me.

[msalsbery]

@INPUTsys-Chris Sorry taking so long! Parallel development with a plugin I’m working on.

I can’t NOT use capture phase...also I can’t find any info that capture-phase events not getting to shadow DOM is not a bug. It really should work. If you can find any info related to that I’d love to see it.

Anyway I’ll check back in over the next few days...getting close to publishing some new stuff...

[msalsbery]

@INPUTsys-Chris I found a Web Hypertext Application Technology Working Group thread related to this (whatwg/dom#685)

This is really a note to myself, but what I need to do (and you could do if you’d like) is make a simple page with the following DOM structure:

Host parent
Host
Shadow root
Parent
Child

Then on each of the four elements (2 DOM, 2 shadow DOM) add event handlers for a custom event in capture phase and bubble phase. In the event handlers writ to console the element name (eg hostparent/host/shadowparent/shadowchild), the event phase value found in the event object (capture/attarget/bubble), and the target object value found in the event object. When the DOMs are fully loaded, raise the custom event

Then try the page in every browser we can get our hands on and note the order and targets in the console output.

I need to read the spec, which will take a while, but it’s my understanding the capture phase will go as far as the host then fire an attarget event at the host, then continue until into the shadow DOM capture phase until target element reached. Then bubble phase events should occur in reverse. The reason for the attarget at host is to hide a closed shadow DOM (shouldn’t see events for elements that are hidden in shadow)

I’m not sure yet if it’s bad browser implementations or something in our MouseTracker implementation that’s causing problems on some browsers

Anyway just checking in...I’m still on it!

[msalsbery]

@INPUTsys-Chris Now that I’ve studied the spec...have you tried an open shadow dom? I don’t think it’s going to work on closed. To work on closed we need to, in the times we respond to capture phase events, listen on the shadow dom’s top element (near the root) instead of document. Browsers that use a documentorshadow mixin it probably works, as document points to the base of the shadow dom as seen from in the shadow dom.

I’ll test this stuff out to confirm, but I think it might be fixable with a relatively minor modification

[Chris-SP365]

Sorry, I'm not very familiar with dom events in shadow dom either. I'm just a regular Vaadin 14 user.

I just had a look at the OpenSeadragon source code again.

In updatePointersEnter, if there is a tracker.dragHandler can't we just return and do nothing?

I mean, it's ok to look at the way events SHOULD happen, but you could also ignore the events which don't fit into the current context.

[msalsbery]

@INPUTsys-Chris Cool thanks, mostly babbling to myself so I don’t forget lol

Anyway I think I have a fix... 🤞

[msalsbery]

@INPUTsys-Chris

I'm finally finishing up an event-handling (MouseTracker) patch!

If you still have shadow DOM code that you can test in, and have a little time, I would LOVE to know if OpenSeadragon viewers work in shadow DOM!

Links to Demos and Preview Builds

Cheers

[Chris-SP365]

Hi,

I guess it's better to continue that discussion in this ticket.

I updated
https://webapps.inputsys.de/test/test
with your new version.

The green rectangle should become red if clicked. Also I added a
alert("msalsbery");
in the code if the click happens, so you can find that part of the code.

It's not very easy to read because vaadin does minify that code but maybe you can set breakpoints.

[msalsbery]

@INPUTsys-Chris excellent, thank you! I’ll have a look later today

Edit: I can't really figure out what's going on in the bundled code. About the only thing I can see is the console output, which is only showing events in the inner/outer viewer MouseTrackers. Is CSS pointer-events set to none on the green box?

I can't tell what's in shadow DOM and what's not, and dev tools shows me a shadow DOM sibling of the viewer which doesn't look right. What's the layout supposed to be? Can you make a development build that's not minified (I'm not familiar with VAADIN at all)?

[msalsbery]

Fixed v2.5.0 (#1872)

[Chris-SP365]

@msalsbery
sorry I've been on holidays. I will try to reproduce/help and respond soon...

[Chris-SP365]

Hi @msalsbery ,

you're right! I solved it by adding pointer-events to the items. Previously they did receive the events without that.

So my issues are fixed now. Maybe we can close that issue.

Thank you very much for your improvements and your support!

[msalsbery]

Fixed for v2.5.0 (#1872)

Feel free to reopen if issue persists!