[BUG] Custom events do not report client_OS correctly

[arielabawol]

Description/Screenshot

Hello,

We use the Application Insights React plugin to track custom events in our React app. When we view those custom events in the Azure Portal an incorrect client_OS is being shown against the events. client_OS is set to Windows 10 instead of Windows 11.

Steps to Reproduce

• OS/Browser: Windows 11 / Chrome v119 and Edge v119 and Firefox v119
• React Version: 18.2.0
• SDK Version [e.g. 22]:
  • @microsoft/applicationinsights-react-js: 17.0.0
  • @microsoft/applicationinsights-web: 3.0.3
• How you initialized the SDK:

const reactPlugin = new ReactPlugin();

const appInsights = new ApplicationInsights({
    config: {
        connectionString: `InstrumentationKey=${applicationInsightsInstrumentationKey};`,
        enableAutoRouteTracking: true,
        extensions: [reactPlugin],
    },
});

appInsights.loadAppInsights();

appInsights.addTelemetryInitializer((env: ITelemetryItem) => {
    env.tags = env.tags || [];
    env.tags['ai.cloud.role'] = 'App';
});

Expected behavior

Windows 11 is shown as the client_OS property of the custom events.

Additional context
I tried upgrading @microsoft/applicationinsights-react-js to version 17.0.2 and @microsoft/applicationinsights-web to version 3.0.5 very briefly, just to check locally if that solves the issue, but it didn't seem to help.

[MSNev]

Yes, this is caused because the UserAgent is now frozen (the browser lies to us via the UA about which OS version it's running on).

And because this information is currently processed by the server it is only receiving the UA (it's not requesting the new Client hints) the best it can currently do is to identify this based on what is provided.

There are a couple of long term internal investigatings (on the client side) that we are planning which (might) help with this -- but I don't have any concrete dates on when the investigation will occur (this is to use the getHighEntrophyData() API (which is asynchronous (which will affect the initial page load), we have already updated the code to use the browser performance timings (rather than the JavaScript time) for reporting the initial page load (this was the first step), the next step is that due to the asynchronous nature of the getHighEntrophyData() call, to correctly "handle" the reporting we would have to delay the page view (even if you ask for it and call flush) -- this is not quite as straight forward as it sounds to do from a generic perspective.