Closed
Bug 1084475
Opened 10 years ago
Closed 2 months ago
Site-specific user agent overrides don't affect navigator.userAgent
Categories
(SeaMonkey :: General, defect)
SeaMonkey
General
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: kevink9876543, Unassigned)
References
Details
As of SeaMonkey 2.30 (at least on Mac OS X and Linux), site-specific user agent overrides do not affect the value of navigator.userAgent. STR: SeaMonkey 2.30, new profile 1) about:config -> create string pref general.useragent.override, give it any value 2) about:config -> create string pref general.useragent.override.addons.mozilla.org, give it any value 3) go to any page on addons.mozilla.org Expected results: the navigator.userAgent property should use the AMO site-specific override Actual results: the value of navigator.userAgent was set to the value of general.useragent.override Further investigation showed that the User-Agent header does pick up the site-specific override. Note that this is different from the bugs in See Also because the global override does affect navigator.userAgent here.
Comment 1•10 years ago
|
||
Odd. Are you seeing siteSpecificUA end up as null in Navigator::GetUserAgent? This was claimed to be fixed in SeaMonkey 2.16, per bug 803172.....
Flags: needinfo?(kevink9876543)
Comment 2•10 years ago
|
||
It seems ar e
Comment 3•10 years ago
|
||
ops.. I was saying, it could be a regression of bug 1062920. Recently NavigatorID.webidl has been changed introducing [Constant, Cached].
Comment 4•10 years ago
|
||
Shouldn't matter as long as the first on the given navigator objects happens after the pref has been set....
Reporter | ||
Comment 5•10 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #1) > Odd. Are you seeing siteSpecificUA end up as null in > Navigator::GetUserAgent? How do I get that information? > This was claimed to be fixed in SeaMonkey 2.16, per bug 803172..... And it worked in SeaMonkey 2.29.1. Something change in either Gecko 33 or SeaMonkey 2.30 that broke this. (FWIW looks like official SeaMonkey nightly is affected by this too)
Version: 33 Branch → Trunk
Comment 6•10 years ago
|
||
> How do I get that information?
Attach a debugger to your SeaMonkey and step through that function? You may need a debug build of SeaMonkey.
Reporter | ||
Comment 7•10 years ago
|
||
Sorry, but I am not techie enough to use a debugger. I've read the docs repeatedly and tried before for other bugs, and I couldn't get my head around it, and each time I actually tried using the debugger, something always went wrong that I couldn't get the requested information. :(
Flags: needinfo?(kevink9876543)
Comment 8•10 years ago
|
||
OK. If this is not reproducible in Firefox, it'll need to be debugged by someone who can in fact debug SeaMonkey... or at least is willing to. _Is_ it reproducible in Firefox?
Reporter | ||
Comment 9•10 years ago
|
||
I'm not sure of what I'm doing in Fx because for some reason I have a lot of trouble navigating Australis. However, my attempt follows: Linux x86_64 1) Download from mozilla.org, the official Mozilla build of Fx 33 for Linux64 2) Install Fx to home directory, start it with new profile 3) In about:config, disable data sharing and automatic updates 4) Follow the exact steps of Comment 0, with global user agent looking like Fx 33 on Windows and AMO specific user-agent looking like Opera 12 on Mac (both obviously fake :P ) ... and AMO thinks I'm on Firefox despite the site-specific override. So if I understood correctly, yes this is reproducible in Fx.
Comment 10•10 years ago
|
||
Thank you for testing that. So I dug into this a bit, and for this override mechanism to work someone needs to call UserAgentOverrides.init(). Nothing does that in desktop Firefox (though the call is made on Android and on b2g). Some bisecting finds bug 896114, which explains what's going on here: this stuff is completely disabled on desktop.
Component: DOM → Networking
Reporter | ||
Comment 11•10 years ago
|
||
Comment 10 didn't seem consistent with my original report, so I played with Fx a bit more, and came to the conclusion that sadly, the issue described in Comment 10 is not related to this bug - the site-specific user-agent header is sent correctly in SeaMonkey (???), where it is not in Firefox (as expected from comment 10). So, moving this bug to SeaMonkey then.
Component: Networking → General
Product: Core → SeaMonkey
Comment 12•10 years ago
|
||
Looks like SeaMonkey does do UserAgentOverrides.init() in suite/common/src/nsSuiteGlue.js. Does SeaMonkey have a JS debugger you could use to debug its chrome? If so, stepping through getOverrideForURI in UserAgentOverrides.jsm (if it's called!) might be informative.
Comment 13•10 years ago
|
||
> Does SeaMonkey have a JS debugger you could use to debug its chrome? If so,
> stepping through getOverrideForURI in UserAgentOverrides.jsm (if it's
> called!) might be informative.
SeaMonkey doesn't have a JS debugger but you an use Firefox to connect to a SeaMonkey instance (in SeaMonkey do: Tools -> Web Development -> Allow remote debugging)
Reporter | ||
Comment 14•10 years ago
|
||
Well, using Firefox as the debugger and setting a breakpoint on the first line of getOverrideForURI, I didn't run across any code that sets navigator.userAgent... However, I don't think that's useful information yet given that I didn't compare to a working SeaMonkey. Will post back with that info later today.
Reporter | ||
Comment 15•10 years ago
|
||
OK, here are the results of the comparison. Firefox 33 is the debugger in both cases. SeaMonkey 2.30: - getOverrideForURI is called when making an HTTP request - no attempt to set navigator.userAgent happens at that time - getOverrideForURI is NOT called when asking for navigator.userAgent from my Web Console add-on SeaMonkey "2.28.2-unofficial-1" (custom build from comm-esr31): - getOverrideForURI is called when making an HTTP request (same as 2.30) - no attempt to set navigator.userAgent happens at that time, BUT... - getOverrideForURI is called when asking for navigator.userAgent from my Web Console add-on So I decided to look at the call stack from the working SeaMonkey when navigator.userAgent is accessed, and that leads to this function in a file named "SiteSpecificUserAgent.js": SiteSpecificUserAgent.prototype = { getUserAgentForURIAndWindow: function ssua_getUserAgentForURIAndWindow(aURI, aWindow) { if (this.inParent) { return UserAgentOverrides.getOverrideForURI(aURI) || HTTP_PROTO_HANDLER.userAgent; } let host = aURI.asciiHost; let cachedResult = this.userAgentCache.get(host); if (cachedResult) { return cachedResult; } let data = { uri: aURI }; let result = cpmm.sendSyncMessage("Useragent:GetOverride", data)[0] || HTTP_PROTO_HANDLER.userAgent; if (this.userAgentCache.size >= MAX_CACHE_SIZE) { this.userAgentCache.clear(); } this.userAgentCache.set(host, result); return result; }, for which this.inParent is true, and the specified return value is spat out. I attempted one more thing, which is use Firefox's debugger to check the corresponding source of SiteSpecificUserAgent.js in SeaMonkey 2.30... and I couldn't, because the script doesn't exist in the debugger! Hope that helps
Updated•10 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 16•10 years ago
|
||
(In reply to kevink9876543 from comment #15) > I attempted one more thing, which is use Firefox's debugger to check the > corresponding source of SiteSpecificUserAgent.js in SeaMonkey 2.30... and I > couldn't, because the script doesn't exist in the debugger! Perhaps this might recognize SiteSpecificUserAgent.js : https://addons.mozilla.org/addon/tiny-javascript-debugger/
Reporter | ||
Comment 17•10 years ago
|
||
I had tried that addon, but had no luck getting it to work / figuring it out (if anything, it recognized _fewer_ scripts than Firefox did). (I suspect the reason SiteSpecificUserAgent.js didn't show up is likely that it just isn't being loaded or called by anything.)
Reporter | ||
Comment 18•9 years ago
|
||
Still present in Nightly (Gecko 38), which is now going to be the next ESR, so having the chance I decided to check official Linux i686 nightly builds to get some sense of a regression range Working: https://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2014/09/2014-09-21-00-30-05-comm-central-trunk/ Broken: https://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2014/09/2014-09-30-00-30-05-comm-central-trunk/ c-c changesets: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=9717f3be5a20&tochange=d9ef713a866e m-c changesets: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5bd6e09f074e&tochange=7c24470b6b3a Nothing stood out in c-c changelogs, but keyword searching the commit messages of m-c would make it look like bug 1069401 is the culprit, and seeing that that patch got uplifted to Gecko 33 / SeaMonkey 2.30 it looks consistent with this bug report.
Reporter | ||
Comment 19•9 years ago
|
||
FWIW, I just hacked together an add-on which works around this bug by 'manually' applying the override to navigator.userAgent (with Object.defineProperty), using Cu.import("resource://gre/modules/UserAgentOverrides.jsm"); UserAgentOverrides.getOverrideForURI(...) to obtain override info, and I can confirm that in SeaMonkey 2.32, UserAgentOverrides.getOverrideForURI looks to be working as expected. So at least that part doesn't seem to need any fixing, this really is only a matter of actually calling getOverrideForURI (and using its return value).
Comment 20•9 years ago
|
||
a MXR search is of no help. http://mxr.mozilla.org/comm-central/search?string=getOverrideForURI Could you post some more of your code?
Reporter | ||
Comment 21•9 years ago
|
||
(In reply to Philip Chee from comment #20) > a MXR search is of no help. > http://mxr.mozilla.org/comm-central/search?string=getOverrideForURI What do you mean? Following your link, I'm using this function http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/protocol/http/UserAgentOverrides.jsm#74 > Could you post some more of your code? Sure, but how would that help here? My code is not usable as a patch for this bug, because a web page can detect its behavior and there's no way completely around it from within JS that I know of... What part of the code would you like to see?
Flags: needinfo?(philip.chee)
Comment 23•4 years ago
|
||
Since we removed site specific UA handling in bug 1513574, we should probably close this bug.
Comment 24•2 months ago
|
||
I agree with Valentin from four years ago.
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•