[EuiDataGrid] Fix full screen display bug

[cee-chen]

Summary

Before

After

Checklist

• Check against all themes for compatibility in both light and dark modes
• Checked in mobile
• Checked in Chrome, Safari, Edge, and Firefox

- [ ] Props have proper autodocs and playground toggles
- [ ] Added documentation
- [ ] Checked Code Sandbox works for any docs examples
- Added or updated jest and cypress tests
- [ ] Checked for breaking changes and labeled appropriately
- [ ] Checked for accessibility including keyboard-only and screenreader modes
- [ ] A changelog entry exists and is marked appropriately

Skipping changelog entry since this bug was caused in recent main and should not have hit an actual release

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_5369/

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_5369/

[chandlerprall]

I was curious why the top positioning is affected by fullscreen or not, and it turns out the cells are positioned relative to the virtualized container until full screen is enabled, then they're positioned relative to their row element.

cell_offset_parent_fullscreen.mov

Looks like the will-change from https://github.com/elastic/eui/blob/main/src/components/datagrid/_data_grid.scss#L25-L27 - added by #3726 - is responsible because transform creates a new stacking context. The will-change attribute was added to solve a performance issue in full screen that doesn't appear to exist anymore, and the css looks like it can be safely removed, keeping the style.top calculation the same for both fullscreen & non-fullscreen experiences.

[cee-chen]

Whoa! TIL that will-change will do that.

The will-change attribute was added to solve a performance issue in full screen that doesn't appear to exist anymore,

Just to clarify, this doesn't exist anymore because we switched to virtualized rendering - is that correct?

[cee-chen]

@chandlerprall Superior fix has been pushed up :)

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_5369/

[chandlerprall]

LGTM! Tested locally & in the published docs; don't forget a changelog! changelog not necessary because the bug didn't get released

Just to clarify, this doesn't exist anymore because we switched to virtualized rendering - is that correct?

I don't remember enough of the context from when the performance issue was discovered, but I believe the lag was from a combination of the cell-hover performance problems (#5136 + #5163) plus the non-virtualized grid having significant re-layouts.