You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
isElementType.js:5 Uncaught (in promise) RangeError: Maximum call stack size exceeded
at Function.isArray (<anonymous>)
at c (isElementType.js:5:17)
at T.click (click.js:17:32)
at Object.ne (dispatchEvent.js:25:160)
at c.type (click.js:23:22)
at Object.ne (dispatchEvent.js:39:13)
at c.type (click.js:23:22)
at Object.ne (dispatchEvent.js:39:13)
at c.type (click.js:23:22)
at Object.ne (dispatchEvent.js:39:13)
Expected behavior
Should not lead to endless loop
Actual behavior
leads to endless loop
User-event version
14.5.2
Environment
nope.
Additional context
I tried debugging it a bit and found that the PR #850 in which the closest label of a click target is selected and that is supposed to break the loop - I'm not sure how?
The text was updated successfully, but these errors were encountered:
hmmmm, so after a bit of digging I found out that the following points hold true:
1.
clicking on a <input> that qualifies as a labeled control does not dispatch a click event, because the input element is matched here via a .closest self-match.
2.
clicking on a custom element that qualifies as a labeled controldoes dispatch a click event, because it cannot be matched in the same way. This behaviour then re-dispatches a click event whose behaviour re-dispatches a click event and so on until the exception above is thrown.
3.
the spec does not specify how user agents should behave sufficiently to warrant either way - dispatching the click event is allowed and not doing so is also allowed.
For example, on platforms where clicking a label activates the form control, clicking the label in the following snippet could trigger the user agent to fire a click event at the input element, as if the element itself had been triggered by the user: [...] On other platforms, the behavior in both cases might be just to focus the control, or to do nothing.
4.
the spec does specify that a user agent should treat labelable elements the same.
This means, as I read it, that the activation behaviour of form-associated custom elements can be left to the user-agent since they should be treated "the same" as other labeled controls. Which in turn means that the correct change imho would be this:
- const control = context && isElementType(context, 'label') && context.control+ const control = context && isElementType(context, 'label') && !(target.constructor as {formAssociated?: boolean}).formAssociated && context.control
This way form-associated custom elements would also not have a defined click behaviour which prevents the endless loop.
Reproduction example
self contained html provided in prerequisites
Prerequisites
loading this throws the following error:
Expected behavior
Should not lead to endless loop
Actual behavior
leads to endless loop
User-event version
14.5.2
Environment
nope.
Additional context
I tried debugging it a bit and found that the PR #850 in which the closest label of a click target is selected and that is supposed to break the loop - I'm not sure how?
The text was updated successfully, but these errors were encountered: