[terra-responsive-element] Issue with repetitive resizing

[JS062512]

Bug Report

Description

When resizing a page with multiple view types, such as different display types for small and large displays, there is a range of widths that can cause the formatting to become inconsistent. While within this width range the object will switch between view types rapidly. Once the view loads, the page seems to update and decide it should switch views, after switching views it then updates again and determines it should switch back to the previous view - creating an infinite loop.
This is a video showing one such page stuck in a loop of switching between two views Video of problem

Steps to Reproduce

1. Slowly resize the width of a page that has a compressed and non-compressed view
2. Once the form switches views stop resizing and see if the view switches once loaded
3. If the view does not switch resize until you go back to the previous view
   (As we are unsure what combination of elements cause this issue it may not work on all pages that use terra-responsive-element)

Additional Context / Screenshots

Our code uses terra-responsive-element and uses terra-table for the expanded version and terra-SingleSelectList for the collapsed version.
For resizing we use default and 'small'

Expected Behavior

Resizing the width to change view types would make this change a single time instead of creating a loop of switching views.

Possible Solution

A possible source of the issue may be how the terra-responsive-element is getting the width for the terra-table and for the terra-SingleSelectList may be inconsistent, causing the view type to switch between the two. It also may be a problem with the scroll bar. Watching the video it seems the expanded version has a scroll bar that includes the header while the collapse version does not.

Environment

• Component Name and Version: terra-responsive-element@3.9.1, terra-table@2.23.1, terra-list@2.23.1
• Browser Name and Version:
• Node/npm Version: [e.g. Node 8/npm 5]
• Webpack Version:
• Operating System and version (desktop or mobile):

[bjankord]

@JS062512 Can we get a reduced test case to help us debug this further.

[tbiethman]

I worked with @JS062512 to dig into this a little more. The issue is indeed caused by the scrollbar, particularly when the scrollbar is rendered as always visible (due to a mouse being detected or other settings being enabled).

I'm not sure how tenable it will be to have the ResponsiveElement account for the presence of the scrollbar in its width-detection logic. The various browser implementations make that tricky, especially so given that a lot of that logic is itself encapsulated within the ResizeObserver.

However, we could institute additional rules around what constitutes a valid ResponsiveElement child in order to help expose and mitigate the problem for consumers. Namely, a direct child of the ResponsiveElement should not be able to overflow; it should instead defer that need (if necessary) to a further child so that the scrollbar presence doesn't impact the element itself.

[tbiethman]

The issue can be reproduced here by slowly transitioning between the tiny and small breakpoints: https://kaiju.cerner.com/projects/icy-mothra-8JU6_w/workspaces/bold-manda-tTn6xQ/preview

[tbiethman]

Instead of introducing constraints on the parent/child items, I think we should be able to just use the parent elements offsetWidth value for our width calculations, as it will include any present scrollbar in the value: https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/offsetWidth

We'd just have to get that value manually instead of using the value directly given to us by the ResizeObserver.

[bjankord]

In addition to this issue, we'll also want to complete the work for #2048 in a separate PR. The goal will be to release the breaking changes in for this issue and the breaking changes for #2048 in 1 major release version.

[bjankord]

Resolved with #2141