-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[code-infra] Playwright 1.49 #15493
[code-infra] Playwright 1.49 #15493
Conversation
Deploy preview: https://deploy-preview-15493--material-ui-x.netlify.app/ |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
@LukasTy I've divided the e2e tests... they are interfering with eachother a lot due to async bleeding everywhere. The This is probably similar reason why the tests are failing on vitest as well. IMO we should look into adding eslint rules to force everyone to use the correct test patterns, though it is a bit difficult cause I think some of the issues come from core's test utils as well 😢 |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
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.
Looks good, leaving some comments. 😉
const virtualScroller = document.querySelector<HTMLElement>('.MuiDataGrid-virtualScroller')!; | ||
expect(virtualScroller.scrollLeft).to.equal(0); | ||
fireEvent.keyDown(document.activeElement!, { key: 'ArrowRight' }); | ||
// We then need to move up to the group header, then right to the first named column | ||
await user.keyboard('{ArrowUp}{ArrowUp}{ArrowRight}'); |
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.
This seems different to the previous behavior on L516. 🤔
Did you have problems with?
await act(() => getColumnHeaderCell(0, 0).focus());
The same question applies to the whole file.
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.
🤔 It should probably work fine.
My main grip is that using .focus()
is not really how the user uses the keyboard. So if you want to test that your behaviour is working properly, you should emulate the entire action.
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.
I would leave this call for @mui/xgrid, but maybe we can create an alternative getColumnHeaderCell
or focusColumnHeaderCell
function, which would click on the respective cell? 🤔
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.
I didn't add clicking on the cell itself cause I don't know if that causes other side effects
Eg: if we have selectable rows and we click on column 0, then it "selects" the row.
Focusing through keyboard interactions seemed more safe.
The main difference on why it has more "keypresses" than before is because the default focus goes to the "effective" first entry on the header if we press tab
, but these tests are testing the column groups, which means they were first focusing on the first ever element on the header getColumnHeaderCell(0, 0)
, rather than the element that gets the focus first, which in this case would be getColumnHeaderCell(0, 2)
So, this means
Previous getColumnHeaderCell(0, 0)
H - Header
C - Content Cell
H00 |
H10 | H20 |
H01 | H11 | H21 |
H02 | H12 | H22 |
--- | --- | --- |
C00 | C10 | C20 |
[Tab]
-> getColumnHeaderCell(0, 2)
H00 | H10 | H20 |
H01 | H11 | H21 |
H02 |
H12 | H22 |
--- | --- | --- |
C00 | C10 | C20 |
I simply moved the focus back to the getColumnHeaderCell(0, 0)
from the original tests.
Now, it might be that the element at 0,2
shouldn't get focus on tab, which would be another problem unrelated to this PR IMO 😅
But the tests are comparable between themselves and the assertions didn't change.
expect(document.querySelectorAll('.MuiTouchRipple-rippleVisible')).to.have.length(1); | ||
}); | ||
}); | ||
// Skip on everything as this is failing on all environments |
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.
Has this started happening only with the bump of playwright
?
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.
Yeah, it was happening since the first run of this PR, but it seems to be fixed if I revert it now... at least locally. I guess dividing the tests helped with the inconsistencies...
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.
Seems to be consistently failing in CI and local ubuntu though... OSX seems fine, though that is of no use for our CI, so I just ignored it again 🙃
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.
Left a new comment on this topic: #15493 (comment)
const virtualScroller = document.querySelector<HTMLElement>('.MuiDataGrid-virtualScroller')!; | ||
expect(virtualScroller.scrollLeft).to.equal(0); | ||
fireEvent.keyDown(document.activeElement!, { key: 'ArrowRight' }); | ||
// We then need to move up to the group header, then right to the first named column | ||
await user.keyboard('{ArrowUp}{ArrowUp}{ArrowRight}'); |
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.
I would leave this call for @mui/xgrid, but maybe we can create an alternative getColumnHeaderCell
or focusColumnHeaderCell
function, which would click on the respective cell? 🤔
}); | ||
}); | ||
}); | ||
// Skip on everything as this is failing on all environments on ubuntu/CI |
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.
have you considered rewriting it with async syntax, not using fake timers, but trying to rely on DOM assertions, like checking if the new item has a ripple effect and only one DOM element has a ripple effect..? 🤔
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.
Yeah, that was the previously commented code. I only in this last commit reverted the ripple logic to the original one. 815810d
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.
LGTM. 👌
Thank you for the massive effort on this one. 💯 🚀
And finding the root cause, why screenshot taking of print preview was failing. 🙈
Most Argos diffs make sense, possibly due to a big jump in browser versions.
But on instance jumps to me: https://app.argos-ci.com/mui/mui-x/builds/27473/122741853
Could this be a fluke? Or a side effect of the moving the mouse?
Maybe with the updates to browser or playwright the initial mouse position is in the middle of the viewport and moving it to 0, 0
causes the controlled highlight to be removed? 🤔
Oh yeah, that was why I moved the cursor to the top on the first place IIRC 🤣 |
Closes #13672.
Closes #14948.