getRtlScrollAxisType detects incorrect RtlScrollAxisType for chrome

[khobabc]

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

I recently upgraded to Angular ~16.2.10, and noticed that cdk-virtual-scroll-viewport is not working in RTL mode for horizontal scroll. Initial data is rendered but then on scroll subsequent records are not rendered.

On investigations I came to know that getRtlScrollAxisType is returning 2 (Inverted) instead of 1 (Negated). If I make it return 1 during debug, things start to work fine.

Reproduction

StackBlitz link: https://stackblitz.com/edit/angular-yehn5j?file=src%2Fapp%2Fcdk-platform-overview-example.html
Steps to reproduce:
Notice that at the bottom of information, getRtlScrollAxisType is 2

Expected Behavior

getRtlScrollAxisType() should return 1 for chrome.

Actual Behavior

getRtlScrollAxisType() returns 2 for chrome

Environment

• Angular: ~16.2.10
• CDK/Material: ~16.2.10
• Browser(s): Chrome 119.0.6045.160, Chrome 119.0.6045.200
• Operating System (e.g. Windows, macOS, Ubuntu): Windows 10 Pro

[mmalerba]

Hmm, it does return 1 as the scroll axis type for me with Chrome on Mac. This might be specific to Chrome on Windows. The logic for calculating the axis type doesn't look at the user agent or anything, it just experimentally determines by adding a hidden scrollable element, so I'm not really sure why it would get it wrong only for Chrome on Windows.

Also nothing has changed about the code recently, so I'm not sure why it would have changed only when updating to Angular 16.2.10.

[khobabc]

You are right, nothing changed code wise, as far as I could tell, but If I still run above blitz on Chrome for Windows, from a separate machine with chrome reinstalled, it is still returning 2.

I am not sure if it is related to upgrade or generic issue, because I noticed it in regression after upgrading Angular.

[khobabc]

Is there any update on this?