Spec Runner overflow issue in Firefox after hovering in the command log

[sync-by-unito]

Current Behavior

Note: This bug would be irrelevant after https://cypress-io.atlassian.net/browse/UNIFY-668 or https://cypress-io.atlassian.net/browse/UNIFY-1546 is completed and prevents needing the scroll, it would probably be better to spend effort on the responsiveness in general than chasing down this issue with FF.

A small enhancement to the Runner - becoming scrollable when the viewport is too small for the AUT to be visible - has the potential to break the UI in Firefox in some narrow circumstances, so I’ve currently turned off that enhancement in FF. It seems likely that it might be related to this category of bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1663634. See missing headers in these panels and the white space the bottom of this screenshot for an example of the bad state:

Desired Behavior

In this situation, Cypress should work the same in both FF and Chromium based browsers

Reproducible Steps

1. Remove the isFirefox check from ResizablePanels.vue so that the overflow-x-auto class is always applied.
2. Open any spec in Firefox.
3. See that sizing/scaling all works normally
4. Make the window small enough that the AUT is too small to see.
5. Hover on a command such that the snapshot pinning UI appears.
6. Notice the UI has all moved up a certain amount.
7. Inspect the DOM to see that the 100vh that sets the height for the container element for the panels is still applied, and the calculated height in the CSS panel matches the window.innerHeight you get in the console.
8. Resize the window bigger and notice that it comes back to normal behavior until you hover on the command log again in the same situation as above.

In my first look I couldn’t see why simply showing and hiding the snapshot controls would produce this effect in Firefox but not Chrome, so I’ve made this ticket to not hold up PR digging in to this part.

┆Issue is synchronized with this Jira Bug by Unito
┆Attachments: Screen Shot 2022-05-02 at 8.51.54 AM.png
┆author: Mark Noonan
┆epic: UI/UX Improvements
┆friendlyId: UNIFY-1704
┆priority: Lowest
┆sprint: Backlog
┆taskType: Bug

[BlueWinds]

This can also be triggered by having devtools docked to the bottom and resizing it:

Potentially easier repro than the one listed in the description.

[marktnoonan]

I took a deeper look since there are now more ways to reproduce. It appears that what's really going on here is that Firefox basing the scrollHeight of the container for the panels off of the initial height of the AUT before it gets scaled. So even though everything looks correct, a scrollable area is created at the bottom of the window. Other browsers do not seem to calculate the scroll height this way.

Most of the time this is fine, users can't scroll there accidentally, due to overflow: hidden. What's surprising is when you hover over certain parts of the command log, it causes FF to scroll the panels area to the bottom for some reason. This can happen without devtools open if users make there window small enough.

There are many CSS tweaks that appeared to fix this when playing with devtools, but in reality it seems that doing those tweaks causes FF to reset the scroll position on its own as it reacts to new CSS from the devtools.

It will take a bit more testing before making a PR, but on this branch the problem should be fixed by taking the scalable AUT element out of the document flow with position: absolute.

firefox.devtools.working.mov

This change will also allow us to remove the isFirefox check from the resizable panels component so FF can be at parity with the other browsers when the Runner overflows.