-
-
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
[DataGrid] Fix multiple focus behaviors #1421
Conversation
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 breaks the roving index, cc @DanailH.
I think that we absolutely need tests for the tab and focus behavior, it's brittle and easy to break.
I can do tests but why is the roving index broken? |
@dtassone One example of regression: https://deploy-preview-1421--material-ui-x.netlify.app/components/data-grid/#mit-version |
@@ -149,6 +153,10 @@ export const GridColumnHeaderItem = ({ | |||
} | |||
}); | |||
|
|||
const isFirstTabbable = |
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'm not sure that the first column header should be tabbable. I was left with the impression that the first cell should be tabbable.
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.
That's the thing, IMO, the first tabbable control of a sortable grid should be the first sortable column header
https://www.w3.org/TR/wai-aria-practices/examples/grid/dataGrids.html
So in our case, I put the first column so we could argue that if none of the columns have an action then it should be the first cell of the first row
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.
Actually, if we use that logic then the first tabbable cell should be either the column header that is sortable or the one that has a column menu as it is also a interaction.
split cell focus state and tabindex state |
I meant that the rating is a radio group, that should handle arrow keys. |
It's on my radar. I'll work on it today. |
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 is not enough to close [DataGrid] Focus lags behind on double click #1420. Only point 3 is fixed. I would recommend we focus on [DataGrid] Broken cell focus on edit with external button #1416 only.
- There is still a regression in the tab index behavior. See how there are two tabbable cells on the page
- We need a test case for [DataGrid] Broken cell focus on edit with external button #1416
keyboard: { isMultipleKeyPressed: false }, | ||
focus: { cell: null, columnHeader: null }, | ||
tabIndex: { cell: null, columnHeader: null }, |
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 looks better. We should soon be able to kill keyboard
with #1437 from @m4theushw.
I would also advocate to kill focus
but it will be for another discussion.
const inputs = document.querySelectorAll('input'); | ||
expect(inputs.length).to.equal(2); | ||
const nikeInput = getCell(0, 0).querySelector('input'); | ||
fireEvent.click(nikeInput); |
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.
@oliviertassinari any idea why this test does not work?
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.
Could we simplify the test case (remove most of the code)? It doesn't seem that we need all this to create a failing test case.
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.
As for why the test case doesn't work. I recall that your first commit was to add a blur listener to fix the issue, so if you don't handle the activeElement, I don't see how the test could work, e.g. calling .focus(). We are inside a browser, fire event click doesn't trigger all the intermediary event (mouse down/mouse up/focus) that a real browse have. You have to simulate them.
Ok I think I found a bug but I'm struggling to make i video of it I'll try and list the steps:
@dtassone if you want to ping me and I will show you the problem if you cant reproduce it. |
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.
The fix seems to work and I can't spot a regression 👍 . I'm adding test cases for the one we found #1459.
const inputs = document.querySelectorAll('input'); | ||
expect(inputs.length).to.equal(2); | ||
const nikeInput = getCell(0, 0).querySelector('input'); | ||
fireEvent.click(nikeInput); |
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.
Could we simplify the test case (remove most of the code)? It doesn't seem that we need all this to create a failing test case.
const inputs = document.querySelectorAll('input'); | ||
expect(inputs.length).to.equal(2); | ||
const nikeInput = getCell(0, 0).querySelector('input'); | ||
fireEvent.click(nikeInput); |
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.
As for why the test case doesn't work. I recall that your first commit was to add a blur listener to fix the issue, so if you don't handle the activeElement, I don't see how the test could work, e.g. calling .focus(). We are inside a browser, fire event click doesn't trigger all the intermediary event (mouse down/mouse up/focus) that a real browse have. You have to simulate them.
I thought it would fire focus on click with fireevent If I simulate the event then the test doesn't fail without the fix |
|
Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
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 look closely in the logic, @m4theushw interested in having a closer look?
I didn't see a test case for the change of focused element for the checkboxes @dtassone what do you think about adding a regulae jsdom/Karma test to cover the new behavior?
I have updated the title so developers can understand the problem solved by this PR once it's displayed in the changelog. Also notice the capitalization so it behaves like a full sentence. |
Preview: https://deploy-preview-1421--material-ui-x.netlify.app/components/data-grid/editing/#edit-using-external-button