Avatar for Username

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

This thread was archived. Please ask a new question if you need help.

FireFox sends wrong user agent for a specific website

  • 3 replies
  • 0 have this problem
  • 23 views
  • Last reply by Umer Khan

Umer Khan
Umer Khan
more options

We have a noticed a very strange behaviour with the latest FireFox (126). One of our webpage is behaving differently across our Integration and production environment. Both env are running identical code and similar network stack the only difference we have noticed so far is for our Integration env Firefox is sending the different user-agent string than for production.

Steps to reproduce: 1. Open https://integration4-view.publitas.com/automation-int4/reader-happy-path/page/1

2. Go to console and view navigator.userAgent the user-agent string will be: 

    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0"

3. Now open the same content on production -> https://view.publitas.com/automation-prod/reader-happy-path/page/1

4. Go to console and view navigator.userAgent the user-agent string will be: 

   "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) FxQuantum/126.0 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.71 Safari/537.36"

Our website changes behaviour based on which browser it is and based on second string our backend interprets the browser as chrome instead of Firefox.

If I change privacy.resistFingerprinting to True then the user-agent string is sent correctly.

Can you please help us identify what changed in the latest version that is causing this behaviour.

Version: 126 (64 bit) Test on Windows 11 and Mac OSX

We have a noticed a very strange behaviour with the latest FireFox (126). One of our webpage is behaving differently across our Integration and production environment. Both env are running identical code and similar network stack the only difference we have noticed so far is for our Integration env Firefox is sending the different user-agent string than for production. Steps to reproduce: 1. Open https://integration4-view.publitas.com/automation-int4/reader-happy-path/page/1 2. Go to console and view '''navigator.userAgent''' the user-agent string will be: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0" 3. Now open the same content on production -> https://view.publitas.com/automation-prod/reader-happy-path/page/1 4. Go to console and view '''navigator.userAgent''' the user-agent string will be: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) FxQuantum/126.0 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.71 Safari/537.36" Our website changes behaviour based on which browser it is and based on second string our backend interprets the browser as chrome instead of Firefox. If I change privacy.resistFingerprinting to True then the user-agent string is sent correctly. Can you please help us identify what changed in the latest version that is causing this behaviour. Version: 126 (64 bit) Test on Windows 11 and Mac OSX
Attached screenshots

All Replies (3)

TyDraniu
TyDraniu
  • Top 25 Contributor
more options

This is due to webcompat issues. See bug 1864903

jscher2000 - Support Volunteer
jscher2000 - Support Volunteer
  • Top 25 Contributor
more options

Starting in Firefox 121, there was a UA override for that domain related to problems zooming/scrolling with the true UA:

If you are able to address the original issue, then it should be possible to get that removed.

As far as what might have changed in Firefox 126 that is causing problems, I suspect it could be turning on support for CSS zoom. https://developer.mozilla.org/docs/Mozilla/Firefox/Releases/126

Umer Khan
Umer Khan Question owner
more options

Thanks guys for confirming the issue. We had tried every possible scenario to figure out where that user-agent was coming from.

I will work with the team internally to get this resolved and then we can remove the override.

Thanks again for fixing it proactively. Just curious how did you notice the issue initially. Was it reported by one of our customers or you pick these up automatically?

Modified by Umer Khan