www.bestbuy.com - Firefox is an unsupported browser

[kdashg]

URL: https://www.bestbuy.com/

Browser / Version: Firefox 110.0
Operating System: Windows 10
Tested Another Browser: Yes Chrome

Problem type: Something else
Description: On latest Firefox Nightly 110, but: We're sorry. Your browser is no longer supported by BestBuy.com. Please download the latest version of Chrome, Firefox, Microsoft Edge, 
Steps to Reproduce:
Loading their home page shows only:

We're sorry.
Your browser is no longer supported by BestBuy.com.
Please download the latest version of Chrome, Firefox, Microsoft Edge, 

Browser Configuration

• None

From webcompat.com with ❤️

[denschub]

Moving this directly into needsdiagnosis as a P1 - it's a high-traffic site, so let's make sure we dig into that and ship an intervention if needed. Also, see this Mozilla-internal Slack thread - we might have a direct way to contact them.

[denschub]

I did some testing, and this doesn't reproduce with the macOS user agent (maybe @wisniewskit can give this a quick test on Linux). Also, the relevant version number appears to be the one inside the parenthesis group, as this user agent

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0

does not get blocked. Chrome's v110 user agent on Windows,

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36

also does not get blocked - but it's notable that they don't even include the browser version inside the parenthesis. If I have a little bit of fun and build a frankenstein's UA string,

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:110.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36

that also gets blocked. So the issue here is the version number in the parenthesis. Unfortunately, this block appears to be server-side, so it's hard to tell what's going on here exactly. But fortunately, this is easy to ship an intervention.

[denschub]

Filed a bug to track that intervention for the v110 cycle: https://bugzilla.mozilla.org/show_bug.cgi?id=1805967

[denschub]

This would be fixed with a frozen rv:109.0 segment, while leaving the other version number untouched.

[webcompat-bot]

Generate outreach template

[rallegretti]

BestBuy.com and Twitch.tv are giving me this same issue. They seem to think the browser is too old, even with the latest release installed that very day.

Using Firefox Developer Edition. My current user-agent is:
[Mozilla/5.0 (Windows NT 10.0; rv:110.0) Gecko/20100101 Firefox/110.0]

Currently using a User-Agent Switcher extension to work around it, but would be nice to have the browsers recognized correctly.

[TheSonu]

I'm having this issue as well using the regular release channel on an M1 Pro Macbook Pro, and can include any relevant issue needed. It's not clear to me if there has been any update issued to fix this. I've tried troubleshooting mode with no luck, while Safari loads www.bestbuy.com without issue.
Useragent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0

[ganakee]

I confirm this serious bug still exists as of 23 February 2023 making BestBuy unusable/inaccessible on Linux.

Firefox 110.0 (x84)
Ubuntu variant 22.04 base (all updates)

Firefox
Version 	110.0
Build ID 	20230214051806
Update Channel 	release
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0

[wisniewskit]

This is odd. I don't get any such lock-outs on Best Buy's site on my Gentoo Linux box, whether I visit the US or Canada pages. Neither does @ksy36 (who tried Ubuntu 22.04.1 LTS with a Firefox tarball from the Mozilla site). @ganakee did you try a different version? If so, mind checking if the version from the Mozilla site also has the problem on your system?

[aner-perez]

I can confirm this is still happening on Firefox 111.0.1 (Fedora 37 with all updates as of today). Switching my Browser Privacy settings from Strict to Standard and reloading the Best Buy page did not help.

Also, trying to generate a report on webcompat.com, the reporting script thought that my OS was Windows 10 instead of Linux (Fedora 37).

[wisniewskit]

@aner-perez This is sounding like it's happening for users with fingerprinting resistance turned on (privacy.resistFingerprinting in about:config, and related settings). I can reproduce the BestBuy lock-out page with that enabled, but not with it off. Could you confirm if it's a setting like that?

[aner-perez]

I can confirm that disabling privacy.resistFingerprinting results in a functional site. I knew I had tweaked some privacy settings recently but I thought toggling privacy from Strict to Standard was enough. Thanks for digging into it!

[wisniewskit]

Ah, good to know! Hopefully @kdashg, @ganakee, @TheSonu,@rallegretti, and @PeteAndersen can confirm if they're also running into this as well.

[AAGaming00]

I'm experiencing this issue on Linux with resistFingerprinting disabled and user agent set to Mozilla/5.0 (Windows NT 10.0; rv:111.0) Gecko/20100101 Firefox/111.0

[aner-perez]

With resistFingerprinting=false my window. navigator. userAgent string is "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0"

With resistFingerprinting=true my window. navigator. userAgent string is "Mozilla/5.0 (X11; Linux x86_64; rv:111.0) Gecko/20100101 Firefox/111.0"

Notice I get rv:109.0 when resistFingerprinting is false and my OS shows Linux x86_64 unlike the agent string from @AAGaming00 which shows Windows NT 10.0. I don't know if these differences are because I use the Fedora packaged firefox or if there is some plugin that may be affecting these user agent strings.

[AAGaming00]

I am using the arkenfox hardened config, which is likely the issue, will try a fresh profile soon

[AAGaming00]

The user agent was manually set to this via user.js

[Thorin-Oakenpants]

@aner-perez This is sounding like it's happening for users with fingerprinting resistance turned on (privacy.resistFingerprinting in about:config, and related settings). I can reproduce the BestBuy lock-out page with that enabled, but not with it off. Could you confirm if it's a setting like that?

@wisniewskit https://bugzilla.mozilla.org/show_bug.cgi?id=1818889 - it doesn't help matters that RFP doesn't use the rv freeze patch, and come ESR115, they will most likely want to implement this

I'm not saying that this is the main or only cause, but it is something that should be aligned

[ChaseKnowlden]

Doesn't show unsupported on Firefox 116

[wisniewskit]

I'm not seeing this anymore for the US and Canada sites, so let's close this. If anyone still sees this, please let us know.