CoPilot picked up some potential issues, including with UserAgent string

[gutley]

Hi, in my fork all PRs go through Copilot for review. While creating the PR for my version of the 149.1 branch it came up with the following suggestions, some of which could fix potential crashes, some are just typos in comments and one involving the creation of UserAgent strings where the OS version is hard-coded:

In BrowserKit/Sources/Shared/UserAgent.swift:

> +        let device = UIDeviceDetails.model
+        let system = device == "iPad" ? "CPU" : "CPU iPhone"
         return UserAgentBuilder(
             product: UserAgent.product,
-            systemInfo: "(\(UIDeviceDetails.model); CPU iPhone OS \(UIDeviceDetails.systemVersion.replacingOccurrences(of: ".", with: "_")) like Mac OS X)",
+            systemInfo: "(\(device); \(system) OS 18_7 like Mac OS X)",

defaultMobileUserAgent() now hardcodes the OS version as 18_7, which will produce incorrect user agents on most devices/OS versions. This should use the actual OS version (e.g., based on UIDeviceDetails.systemVersion with . replaced by _) to avoid web-compat and analytics issues.

Interestingly it only picked up the hard-coded version in defaultMobileUserAgent and not the one in defaultDesktopUserAgent.

Looking at how the user agent string differs from Safari for desktop and mobile in iPad OS 26 (From https://www.whatismybrowser.com/detect/what-is-my-user-agent/):

iPad and iPhone Desktop

Firefox: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.6 Safari/605.1.15
 Safari: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.4 Safari/605.1.15

The only difference is the Version/[18.6|26.4] and I assume Firefox is wrong here in saying its 18.6

iPad Mobile

Firefox: Mozilla/5.0 (iPad; CPU OS 18_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) FxiOS/149.1 Mobile/15E148 Safari/604.1
 Safari: Mozilla/5.0 (iPad; CPU OS 18_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.4 Mobile/15E148 Safari/604.1

iPhone Mobile

Firefox: Mozilla/5.0 (iPhone; CPU iPhone OS 18_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) FxiOS/149.1 Mobile/15E148 Safari/604.1
 Safari: Mozilla/5.0 (iPhone; CPU iPhone OS 18_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.4 Mobile/15E148 Safari/604.1

For mobile the main difference is the swapping of the Version/... section with the FxiOS/... section.
I don't know enough about all the shenanigans that have been needed to get various websites to play nicely with Firefox, but I do wonder if the lack of the 'Version/...` section in our Mobile UserAgent is troublesome???

Anyway, here's the original rtf file with all the suggestions and better formatting:
Copilot issues.rtf

[gutley]

Note, that CoPilot didn't scan the entire source tree, it only did 275 files, which all seemed to be in BrowserKit. No idea what it would find in the other 3000ish files 😀

[janbrasna]

Webcompat. This is tracked in issues and PR threads if you blame the lines.

If you're not interested in these exact values in your fork, revert the changes, or generally feel free to do whatever suits your case, or what other forks do.

[janbrasna]

18_7 constant:

• iOS 26 will freeze OS user agent bit at 18_7 #29263
• Refactor FXIOS-13467 [webcompat] Freeze iOS version in UAstring at 18_7 constant #29548

Desktop UA Version/ value:

• Unsupported browser warnings due to faking Safari 16 UA #27698
• Refactor FXIOS-12716 [webcompat] Use latest UAstring versions for desktop mode #29138 with rationale in former Refactor FXIOS-12716 [webcompat] Update uastring versions #27699 (comment)

It's pointing at Safari version, not OS version, and these do not need to match (e.g. iOS 18.4.1 would be running Safari 18.2 et al.) — in past there was code to get the defaults from OS but has not been reliable for years, so it's currently hard-coded. (At the ultimate release on the previous major for ease of maintenance at this point. But that might need to change as there's already signals from Zoom or Slack to start blocking users accessing their services earlier than a year after the new major, so we might need to start managing that value more frequently.)

[janbrasna]

"if the lack of the 'Version/...` section in our Mobile UserAgent is troublesome?"

Yes. (… and no, at times.)

Feel free to open an issue specific to this, as there definitely pros and cons of having it mimic and track Safari versions, and also not have it at all.

There are apps that fail to sniff UA with this bit missing (most often seen as "Your Safari version: 0 is outdated. Upgrade.") so site patches are being added for these. (ServiceNow, government, healthcare…)

At the same time, once you add the Safari version, some apps actually expect real Safari and start using wild intents/schemes that basically switch you out from your browser to mobile Safari without asking, through deeplinks on the system level. (Xitter…)

Some other browsers get away with having Version/ and CriOS/ at the same time circumvent the logic at the affected sites, but that means support in libs. Most of the libs out there are unmaintained legacy crud. So expecting to get special cased after changing this surface "today" is unrealistic in many of the projects and/or their ancient deployments.

At the same time, these already can get away with no Version/ too as their CriOS is already special cased in the libs to start with, so they don't parse to bogus Safari version, but their own version patterns are correctly recognized.

Basically you don't want to touch these things, as most of the logic you'd be breaking in archaic code out there won't ever change (update, get a new dependency, deployment etc.)

[gutley]

Thanks - I did suspect a can of worms