We're calling on all EU-based Mozillians with iOS or iPadOS devices to help us monitor Apple’s new browser choice screens. Join the effort to hold Big Tech to account!

Caută ajutor

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.

Află mai multe

Acest fir de discuție a fost arhivat. Adresează o întrebare nouă dacă ai nevoie de ajutor.

FireFox sends wrong user agent for a specific website

  • 3 răspunsuri
  • 0 au această problemă
  • 23 de vizualizări
  • Ultimul răspuns de 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
Capturi de ecran atașate

Toate răspunsurile (3)

more options

This is due to webcompat issues. See bug 1864903

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

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?

Modificat în de Umer Khan