Support inputs in shadow DOM in disableOnInputFields mode #578
Conversation
| @@ -70,10 +70,10 @@ export default class KeyboardService extends Service { | |||
| @action | |||
| _respond(event) { | |||
| if (this._disableOnInput && event.target) { | |||
| const tag = event.target.tagName; | |||
| const target = event.composedPath()[0] ?? event.target; | |||
There was a problem hiding this comment.
Note that composedPath is supported in all browsers except IE. But I believe this addon does not support IE anyway, right? Otherwise we could add a better check and fall back to event.target if not supported...
|
Looks good @simonihmig. Thanks for your work on this. Should we also have a positive test case of an event being handled properly in a shadow DOM situtation? I would hate to accidentally break this in a future change. |
Sure, I can do that. I would submit a separate PR, if you agree, as this is not so much about the fix here (specific to detecting inputs), ok? Someone still needs to enable the CI workflow to run btw! 😉 |
|
@simonihmig CI is green! |
|
Thanks @simonihmig and thanks for reviewing @SergeAstapov! |
I tried #557 with the new release, but it failed for us due to a special circumstance in our particular app: we embed it into a 3rd party pages, and for better encapsulation we wrap the whole app inside a shadow DOM.
This however comes with some side effects, also encountered in other places, especially due to the way events are handled across shadow boundaries: when the key event traverses the shadow root, its
event.targetis not anymore the (input) element the event originated from, but the shadow root (to "hide" the internals of the shadow DOM for the outer DOM). So now it's tagName is notINPUTanymore, breaking the input/textarea detection.This PR tweaks the input detection just a little bit, to also support inputs inside a (open!) shadow DOM, by looking for the "real" event target using compoundPath.
Note that the change here is not only related to our particular use case of having the whole app wrapped in a shadow DOM. It should work also in the more general case, e.g. when rendering a custom element that contains an input. This scenario is replicated in the test I added here!
cc @st-h