1433676 - (general.useragent.override.[domain]) Sub-Document fetches do NOT honor "general.useragent.override.[domain]" setting

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect, P5)

Description

[©TriMoon™ Away from Bugmail unless has need to visit]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180127100319

Steps to reproduce:

Use these in the admin.cfg file, or as normal prefs outside it.
----------------------------------------------------------------------------------------------------------------------
// We DONT want to use this because it modifies UserAgent tobe a Windows OS...
// This is also needed to prevent overides by this "feature" that could interfere...
lockPref(	'privacy.resistFingerprinting',					false	)
// Allow us to Fix UserAgent
lockPref(	'general.useragent.site_specific_overrides',	true		)
// Fix the UserAgent
// use any other domain instead of 'localhost' if you need to
lockPref(	'general.useragent.override.localhost',			'Mozilla/Nightly (Current; Test;)'	)
----------------------------------------------------------------------------------------------------------------------


Actual results:

With the above prefs used, navigate to any URL, on the domain as set in the prefs above.
You can check the usage of the UserAgent using the Network tab inside Developer Tools.
The pref-fixed UserAgent is only used in the main document fetched, eg the one entered in the URL-Bar
The *original/default* UserAgent will be used for sub-document fetches, eg. for scripts/images/etc loaded from that main document.



Expected results:

The pref-fixed UserAgent should be used as the default UserAgent for all sub-document fetches, except when explicitly set to something different in case of Ajax/fetch ofcourse :)

Comment 1

[©TriMoon™ Away from Bugmail unless has need to visit]

Just updated the branch because the same happens with Developer Edition

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

Thank you for the bug report. Can you use the mozregression tool (http://mozilla.github.io/mozregression/) to help us narrow down when this stopped working for you?

That tool has the potential to narrow down the point at which this stopped working to the exact change that broke it.

Comment 3

[©TriMoon™ Away from Bugmail unless has need to visit]

Hmm i never worked with that tool before...
I'll try DL and install it on Debian 9.3 and see if i can get it to work.

PS: Before using this tool i just checked and seems my "FF-ESR 52.6.0" does not change the UserAgent at all with given config.
  - (Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 ID:20180123215146 CSet: Undefined

Comment 4

[©TriMoon™ Away from Bugmail unless has need to visit]

I just tried to start './mozregression-gui' after unpacking it in a directory as told, but i can't get it to work on Debian 9.3.

  - 1st try gave error:
> ./mozregression-gui: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
  - 2nd try after doing 'sudo apt-get install libssl1.0.0', gave errors again:
> /opt/firefox/mozregression-gui/mozregression-gui/requests/__init__.py:80: RequestsDependencyWarning: urllib3 (1.22) or chardet (2.0.1) doesn't match a supported version!
> Traceback (most recent call last):
>   File "/home/travis/build/mozilla/mozregression/venv/local/lib/python2.7/site-packages/cx_Freeze/initscripts/Console.py", line 27, in <module>
>   File "mozregui/main.py", line 7, in <module>
>   File "ExtensionLoader_PyQt4_QtGui.py", line 22, in <module>
>   File "ExtensionLoader_PyQt4_QtGui.py", line 14, in __bootstrap__
> ImportError: libQtGui.so.4: cannot open shared object file: No such file or directory

So at this point I'm uninstalling libssl1.0.0 and mozregression-gui again and giving up...

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

Ehsan, could this be fallout from bug 1347425?

Comment 6

[©TriMoon™ Away from Bugmail unless has need to visit]

Just checked on Android Nightly and same issue...

Comment 7

[©TriMoon™ Away from Bugmail unless has need to visit]

Arthur Edelstein (Tor Browser dev), what is your p.o.v. on this?

Comment 8

[Arthur Edelstein [:arthur]]

Indeed this looks like a fingerprinting problem. Thanks for bringing it to my notice. I haven't yet investigated how it will interact with privacy.resistFingerprinting.

Comment 9

[(no longer active)]

(In reply to (away, backlogged on reviews) Jared Wein [:jaws] (please needinfo? me) from comment #5)
> Ehsan, could this be fallout from bug 1347425?

It is certainly possible but the bug doesn't provide enough information, so it's also possible that this has regressed by any other change!

Alice, is it possible that you can help us find a regression range for this please?  Thanks!

Comment 10

[Alice0775 White]

#1 Regression window:
Both Main-Document and Sub-Document are broken.

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3d40d270c031&tochange=c2b375f3a909

Regressed by:
	76a31c4050cc	Dão Gottwald — Bug 896114 - Don't initialize UserAgentOverrides on desktop. r=dolske


#2 Pertial fix:
Fixed for Main-Document. However, Sub-Document is still broken.

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c8e078d00d470a4da27a61425404de90782d9943&tochange=ae40354e5a083eb11e1491028d0cdfe3be5e31a8

Pertial fixed by: 
	1f5e8370f845	Ehsan Akhgari — Bug 1351980 - Initialize and uninitialize UserAgentOverrides.jsm for Firefox; r=mconley

Comment 11

[Alice0775 White]

s/Pertial/Partial/g

Comment 12

[Julien Cristau [:jcristau]]

If this is a 5 year old regression, it doesn't seem worth tracking

Comment 13

[©TriMoon™ Away from Bugmail unless has need to visit]

@Julien, i guess if it was up to you you would label it wontfix period huh?
Maybe this hidden flaw should get more media attention to label firefox privacy insecure ?
Then finally Google Inc. will have won the battle vs Firefox by killing it at last....

Comment 14

[Valentin Gosu [:valentin] (he/him)]

Since UserAgentOverrides.jsm was removed in bug 1513574, we can close this bug now. It's no longer applicable.