Give the grid the whole window
Somebody on your team is booking a morning of work orders. Site, asset, engineer, hours, parts, a line of notes, then the next one, then the next one. The grid they are doing it in sits in a panel on a dashboard, under a title bar and beside two charts, because that is where the screen was designed to put it and the dashboard has other things it wants to show.
So they see a handful of rows at a time. Every few orders they scroll, lose the row they were on, find it again, and by lunchtime they have done more scrolling than typing. Nobody raises a ticket about this. What they do instead is open a spreadsheet, work there where the window is theirs, and paste the results back at the end of the morning. Now there are two copies of the data and a paste step that nobody tests.
The window was there the whole time
The grid above is in a panel of exactly that shape, and it has a control in its left-hand rail that fills the browser window with it. Same grid, same rows, same filters. What changes is how much of the work is visible at once: the notes stay readable without pushing the parts column off the end, and a queue that was being read a few rows at a time becomes a queue you can see.
Escape puts it back into the panel. So does the same button, which by then is offering to restore rather than to maximise.
That is the entire interaction, and the reason it is worth a post is not the button. It is that the person doing the booking can decide, order by order, whether this is a moment for the dashboard or a moment for the data, without asking anybody for a wider screen, a second window or a different page.
What comes with you, and the one thing that does not
The half of this that goes wrong elsewhere is the return trip. Where a screen has to be told how to go full screen, what usually happens underneath is that the grid is thrown away and built again at the new size. Everything the person had set up goes with it: the filter they were working under, the rows they had picked out, the sort they had chosen.
Try the round trip on the grid above. It arrives with five orders ticked. Maximise it, and the same five are still ticked, with room to show them. Come back, and they are still ticked. Filter or sort first, if you want a harder test, and that survives too. Nothing is reloaded and nothing is rebuilt, because the grid is moved rather than recreated, and the work you had done to the screen is not something the grid has to remember and restore.
Your place in the queue comes with you too, and it is worth saying how we checked, because the obvious measurement gets this wrong. The raw scroll offset does reset: the window is a different height when the grid fills it, so a pixel position from the old layout would put you somewhere arbitrary. What the grid keeps is the row. Measured on this build, sitting on order 1682 with two ticked: the same row is at the top of the screen before, during and after, and both ticks survive. You are looking at the same work, in a bigger window.
Why this is not a feature request you should have to make
Filling the window sounds like the sort of thing any application can add in an afternoon, and the first version usually can. The afternoon goes on the second version: keeping the selection, keeping the filters, keeping an open editor from being discarded mid-word, getting the grid out from under a dashboard’s own stacking rules, and putting it back into a layout that has since resized. That is somebody’s time, spread thinly over a year of small corrections, for a feature nobody will ever compliment.
When the grid has no concept of it, that work lands on your team, and it lands again every time the surrounding page changes. When the grid does have a concept of it, the people doing data entry get a bigger window on the day you upgrade and your developers get that time back.
The other thing that quietly stops is the spreadsheet detour. People move work into a spreadsheet because a spreadsheet gives them the whole screen and your application does not. Give them the screen and much of that reason goes, along with the pasting, the version confusion and the awkward conversation about which copy was right.
Your users get this because it ships in the grid. Nobody on your team builds it, maintains it, or fields the ticket about the panel being too small to work in.