ModusTable - row actions - header scrolling when maxHeight is used to scroll table data

[axelsean]

Prerequisites

• I have searched for duplicate or closed issues
• I have read the contributing guidelines

Describe the issue

Using ModusTable there are 100 data rows, but to use the page efficiently only 400px worth - set by maxHeight are used.

Each row has a row action

When the table data scrolls, the row action scrolls, BUT the row action header also scrolls

Row.Action.Scrolling.mov

Code used

<ModusTable columns={tableColumns} data={gridData[object.instanceId] || []} sort={true} onSortChange={(event: ModusTableCustomEvent<ModusTableSortingState>) => handleSort(event)} sortIconStyle={"directional"} showSortIconOnHover={true} maxHeight="400px" manualPaginationOptions={paginationOptions} onRowSelectionChange={(e: ModusTableCustomEvent<unknown>) => handleRowSelection(object, e.detail)} rowActionsConfig={object.actions && object.actions.some((action: any) => action.rowSpecific)? { header: "Actions" } : undefined} rowActions={rowActions} />

Reduced test cases

No response

What operating system(s) are you seeing the problem on?

No response

What browser(s) are you seeing the problem on?

No response

What is the issue regarding ?

@trimble-oss/modus-web-components

What version of npm package are you using ?

No response

Priority

High

What product/project are you using Modus Components for ?

Trimble Unity Pavement

What is your team/division name ?

AgileAssets

Are you willing to contribute ?

None

Are you using Modus Web Components in production ?

No response

[github-actions]

Hello @axelsean! Thanks for opening an issue. The Modus core team will get back to you soon (usually within 24-hours) and provide guidance on how to proceed. Contributors are welcome to participate in the discussion and provide their input on how to best solve the issue, and even submit a PR if they want to.

Please wait until the issue is ready to be worked on before submitting a PR, or you can reach out to the core team if it is time bound. For trivial things, or bugs that don't change the expected behaviors and UI, you can go ahead and make a PR.