It is possible to set the Useragent string by setting "global.useragent.override" in user.js or prefs.js. However, some plugins (notably Java 1.3) query the Useragent to determine if they're loadable or not. Plugins should see the actual Useragent of Mozilla, while websites should see the useragent overridden in the .js files. (I realize this isn't strictly speaking a bug, which is why I've filed it under "enhancements.") Thinking about it, though, I suppose it's possible that someone might want to set the useragent on a per-plugin basis, too. I don't think we'll go into that here. I don't actually have any coding experience with Mozilla, but I'd be willing to dive into this one to see if there's something I can do (unless there's someone with experience in this area who'd feel like looking at it and be able to whip up something much more quickly).
I have absolutely no idea who is responsible for useragent stuff...XP Apps maybe? Hopefully asa knows... ->asa
Assignee: bnesse → asa
Component: Preferences: Backend → Browser-General
QA Contact: sairuh → doronr
The most urgent need to this is to solve a crash which happens when the user agent is changed to something like IE and Sun Java plug-in refuses to work (Sun will not fix this - see bug 83376). Presently to spoof IE (for QA work) I have to uninstall the Java Plugin first. Of courese finding the offending code in Mozilla (the actual crash is Mozilla fault) should be simpler, but this solution is much more general than a fix for one Java plug-in.
Assignee: asa → pchen
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
QA Contact: doronr → sairuh
Assignee: pchen → av
Component: XP Apps → Plug-ins
QA Contact: sairuh → shrir
"Real one" is now actually a plugin (!), so summary --> "... actual one...." Maybe it's impossible to fix this bug. Does Mozilla know it will be opening a plugin ahead of time, so it could pass the actual useragent string?
Summary: Separate the useragent used by http from the real one seen by plug-ins → Separate the useragent used by http from the actual one seen by plug-ins
future for now
Priority: -- → P5
Summary: Separate the useragent used by http from the actual one seen by plug-ins → [RFE]Separate the useragent used by http from the actual one seen by plug-ins
Target Milestone: --- → Future
The plug-ins triage team (av, beppe, peterl, serge and shrir) have reviewed this issue and have made the following determination: This is a low priority request and we will try to get to this at a later date. Assigning to peterl, he has another bug that needs to be resolved and this fits with that issue
Assignee: av → peterl
Whiteboard: [RFE] → [RFE][PL2:P5]
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: normal → enhancement
Summary: [RFE]Separate the useragent used by http from the actual one seen by plug-ins → Separate the useragent used by http from the actual one seen by plug-ins
Whiteboard: [RFE][PL2:P5] → [PL2:P5]
I agree that this enhancement is desirable but low-priority. Is it possible for, let's say, a Java applet to send back data (e.g., the UA string as it sees it) over the Web? If it is, wouldn't that defeat the UA spoofing privacy if this bug gets fixed?
I don't want to do this. If you change your UA string then plugin compatibility is one consequence you might have to deal with.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.