fix: Mouse panning when used in shadow DOM #448
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related issue: #371
This fixes an issue where mouse event panning wasn't functional when the component was used within shadow DOM.
This is due to event retargeting. When the
mousemove
/etc events bubble up from within the shadow DOM, the event target gets set to the shadow DOM's host element. This breaks an assumption in the panning event handler thatevent.target
will be a descendent of thewrapperComponent
, so when the library callswrapperComponent.contains(event.target)
, the result is alwaysfalse
.This PR addresses the issue by checking if the event target is a shadow DOM host. If it is, we check if
wrapperComponent
contains any elements returned byevent.composedPath()
, instead ofevent.target
.event.composedPath()
returns an array with the full bubbling path of the event and is designed for situations like this.Here's a diagram which, uhh, seemed like a good idea at the time: