-
Notifications
You must be signed in to change notification settings - Fork 668
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(trigger('focus')) added natural to jsdom behavior #1777
Conversation
Added test case and the fix for wrapper trigger
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I guess! I am not sure exactly what happens in a browser when you do focus - like you are supposed to trigger some other events manually. But this seems purely additive.
I wonder if we can do something similar in vue-test-utils-next?
I have not worked with -next yet. I believe when you work on the edge between vue and DOM something similar can occur. So For me simulation of natural behavior is what makes the developer experience more enjoyable. |
Yep, agreed on a good DX. What I mean is we should try keep both this and -next the same; so we should port this at some point. |
I think this PR broke the wrapper.emitted(). Supposing we have a button with In a previous version this worked correctly. |
@bel3atar Hi!
<template>
<div>
<button type="button" data-test="button" @focus="$emit('focus')">test</button>
</div>
</template>
<script>
export default {};
</script>
import TestEventChild from '../TestNativeEvent.vue';
import { shallowMount } from '@vue/test-utils';
describe('Button focus', () => {
it('should correctly pass emits', async () => {
const wrapper = shallowMount(TestEventChild);
expect(wrapper.emitted('focus')).toBeFalsy();
await wrapper.get('[data-test="button"]').trigger('focus');
expect(wrapper.emitted('focus')).toBeTruthy();
expect(wrapper.emitted('focus').length).toEqual(1);
});
}); |
@Th3Un1q3 No idea what is going on, but I can reproduce with this simple example |
Ok, I see the difference is that in your example button is a root element. I'll try to dig this way. |
wrapping the button in a div doesn't change anything, the test still fails |
My project doesn't use @vue/cli-plugin-unit-jest |
I think I am running into the same issue as @bel3atar. I am trying to upgrade to v1.2.0 in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61293 but have a few failing tests related to
So far I haven't been able to identify what is causing the issue, but I'll keep playing around with it and see if I can narrow it down. |
1.2 (minor version bump) touches a few particularly complex and gnarly parts of the code base. That's probably what led to this regression. If you (or someone) can find out the problem and submit a fix (or even a good reproduction and explanation, possibly isolate the problem) that would be really useful. I think we can do another really release soon (1.2.1) to fix these problems once we have a fix. The way I usually do this is
This is a brute force, kind of slow but reliable way to isolate the offending commit. |
@phegman hi, what jsdom do you use in your tests? I suspect it can behave differently. |
@Th3Un1q3 It does look like it might have something to do with the I took a look at a fresh install with Vue CLI and it looks like it uses So long story short my conclusion is it may have something to do with the |
@Th3Un1q3 maybe it has something to do with this: https://github.com/jsdom/jsdom/releases/tag/16.4.0
Not sure what a "disconnected element" is though |
Ahhh okay I think the "Fixed el.focus() to do nothing on disconnected elements." change in If I change my tests to use the |
I guess that makes sense in some kind of weird DOM-like manner. Good to hear it's fixed - seems like there isn't any work to be done here. |
@lmiller1990 yeah I would say it is more of a workaround than a fix. I could see this becoming more of an issue if Vue CLI upgrades Anyways thanks all for the help in debugging this 🙂 |
Hmm, I'm not sure it makes sense to work around what appears to be an intentional part of jsdom. It's likely that somewhere in the spec it says "you cannot focus an input not on the DOM". I'd say we should try running the same test in a real browser, without using An alternative in the meantime might just be documenting |
@lmiller1990 fair point, maybe it makes more sense to document this caveat with |
Sure, feel free to make a PR if you have a chance, or I can do it when I get some time. |
FYI: environment: |
For me, the changes in this PR are causing environment: |
One thing you can try is ensuring you mount with Not sure if that is the actual issue here, but worth a try. |
Thanks. I already tried
|
Hm okay that's interesting, we should just compare the two and figure out the difference. I think the |
I just had a look, but I fear your code base is so unfamiliar to me that it would take me a long while to be of much use. In case it helps, you can see that in the vue-datepicker project I've been contributing to, the tests in commit |
Hm okay, not sure I can fix it right now but will leave some info here for the future if someone or myself has time
Both use
I guess there is some difference. I think the first step would be reproducing the bug in this code base in a test.l |
When I have a component that manipulates the focus of multiple inputs, I expect that
wrapper.trigger('focus')
would really focus an input, but actually, it does not.This PR introduces a way of triggering some kind of events more closely to their natural behavior.
What kind of change does this PR introduce? (check at least one)
Does this PR introduce a breaking change? (check one)
If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:
dev
branch.fix #xxx[,#xxx]
, where "xxx" is the issue number)If adding a new feature, the PR's description includes:
Other information:
Added a test case and a fix for wrapper.trigger.