Last Comment Bug 83376 - Crash loading Java Plugin if UserAgent string is changed ("Java Plug-in for Netscape Navigator should not be used in Microsoft Internet Explorer")
: Crash loading Java Plugin if UserAgent string is changed ("Java Plug-in for N...
Status: RESOLVED WORKSFORME
redesign
: crash
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: x86 All
: -- critical with 28 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 89132 92775 95786 97596 105259 106727 111281 117705 134779 140215 140791 146093 164823 170025 171550 172724 173248 175247 175500 183900 186240 186913 187402 196311 196842 200968 202134 213106 233581 234041 236430 238244 242306 249594 258559 261317 261592 261706 269289 269948 270652 270939 271006 272047 272049 272539 275501 278734 284681 285753 312757 (view as bug list)
Depends on:
Blocks: 46029 71569 98995 101353 106727
  Show dependency treegraph
 
Reported: 2001-05-30 14:53 PDT by Erich 'Ricky' Iseli
Modified: 2013-05-29 17:18 PDT (History)
110 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Java Plug-In error message (16.01 KB, image/png)
2001-05-30 14:55 PDT, Erich 'Ricky' Iseli
no flags Details
Possible fix, #1 (1.53 KB, patch)
2001-10-25 06:55 PDT, Alexander Zuev
no flags Details | Diff | Splinter Review
Possible fix, part 2 (1.42 KB, patch)
2001-10-25 06:56 PDT, Alexander Zuev
no flags Details | Diff | Splinter Review
Possible fix, part 3 (776 bytes, patch)
2001-10-25 06:56 PDT, Alexander Zuev
no flags Details | Diff | Splinter Review
Possible fix, part 4 (745 bytes, patch)
2001-10-25 06:57 PDT, Alexander Zuev
no flags Details | Diff | Splinter Review
example showing how to change UA with Javascript through HTML (599 bytes, text/plain)
2002-06-07 09:22 PDT, Peter Lubczynski
no flags Details
re-assemble useragent string instead of getting it through nsIHttpProtocolHandler::GetUserAgent (2.14 KB, patch)
2004-02-02 21:26 PST, Kyle Yuan
xiaobin.lu: review+
Details | Diff | Splinter Review
a new method to get "system" useragent (4.72 KB, patch)
2004-02-04 02:07 PST, Kyle Yuan
no flags Details | Diff | Splinter Review
Message window when opening FireFox, while defalt set to IE. (28.09 KB, image/jpeg)
2004-09-10 11:49 PDT, Corey Small
no flags Details
Manual removal instructions for those not following the comment trail (954 bytes, text/plain)
2004-11-27 16:29 PST, James Laver
no flags Details
improved User Agent Switcher extension as a workaround (or a bugfix?) (32.32 KB, application/x-xpinstall)
2007-07-11 06:18 PDT, patch_linams
no flags Details
An early (not final) version of the fixed extension was attached earlier. Here is the right one :-) (32.65 KB, application/x-xpinstall)
2007-07-12 16:37 PDT, patch_linams
no flags Details

Description Erich 'Ricky' Iseli 2001-05-30 14:53:46 PDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 The lizzard 0.9x rules! (compatible; MSIE 5.0; Windows
98; DigExt)
BuildID:    2001-05-27

I've modified the UA string of the browser. Since then, no way to start browser
again because of an error message which says: "Java Plug-In for Netscape should
not be used with the Microsoft Internet Explorer. Please use the Java Plug-In
for Internet Explorer instead." (see attached image, text in German - probably
because it's taking the Java Plug-In from my StarOffice 5.2 which is in German;
my Windows is also in German by the way, maybe this is the cause.)

Reproducible: Always
Steps to Reproduce:
1. I added exactly the following line in the prefs.js of my profile:
user_pref("general.useragent.override", "Mozilla/4.0 The lizzard 0.9x rules!
(compatible; MSIE 5.0; Windows 98; DigExt)");
2.Launche Mozilla by clicking on its icon

Actual Results:  Error message like quoted above.

Mozilla Crashes (segfault) with following details:

MOZILLA verursachte eine allgemeine Schutzverletzung
in Modul GKCONTENT.DLL bei 015f:602c22c9.
Register:
EAX=008a5ad0 CS=015f EIP=602c22c9 EFLGS=00010246
EBX=0068abfc SS=0167 ESP=00000000 EBP=0068f940
ECX=01a15e8c DS=0167 ESI=0068f95c FS=7147
EDX=0068f948 ES=0167 EDI=00000000 GS=0000
Bytes bei CS:EIP:
a7 24 60 5f a7 24 60 69 a7 24 60 5e e7 23 60 68 
Stapelwerte:
00c80f9e 00700465 0a2d0016 00700465 00700465 f000ff54 f000e140 f000ef6f d0000000
0b0708d2 0a2d003a 0a2d0052 0a2d006a 0a2d0082 0a2d009a 00700465 

Expected Results:  Like it behaves when there is a parameter, like explained below.

*Note:* This bug doesn't reproduce only if there is a parameter in the command
line. For example I use "mozilla.exe -turbo". This doesn't cause the above
behavior. But if you launch mozilla without any modifiers, it crashes always.
Comment 1 Erich 'Ricky' Iseli 2001-05-30 14:55:01 PDT
Created attachment 36547 [details]
Java Plug-In error message
Comment 2 shrirang khanzode 2001-05-30 14:55:49 PDT
component: OJI
Comment 3 Erich 'Ricky' Iseli 2001-05-30 15:03:35 PDT
Not Blocker, just Critical...
Comment 4 Erich 'Ricky' Iseli 2001-05-30 15:06:55 PDT
Correction: I notice that I crash when I'm loading Mozilla with a modifier:
mozilla.exe -P "Profilename". So what I said above is not true. have to make one
more test if it crashes WITHOUT modifiers.
Comment 5 Erich 'Ricky' Iseli 2001-05-30 15:11:50 PDT
Ok. No crash if run without modifiers. Crashes only if
-P "Profilename"
maybe there are other modifiers but I didn't test them.

Sorry for all this spam.
Comment 6 edburns 2001-06-04 12:59:25 PDT
I have confirmed this happens on win32.  I have filed Sun internal bugtraq bug 
4465932.  Re-assigning to Jim.
Comment 7 edburns 2001-06-25 16:13:01 PDT
Marking INVALID [jpibug]
Comment 8 Erich 'Ricky' Iseli 2001-06-25 21:38:24 PDT
What is jpibug meaning? Could anyone provide a link to the bug report at sun?
thanks.
Comment 9 edburns 2001-07-09 17:52:56 PDT
*** Bug 89132 has been marked as a duplicate of this bug. ***
Comment 10 edburns 2001-07-17 12:54:26 PDT
FYI, Here's the reply from Sun:

> Java Plug-in depends on user-agent string for version information, no fix
> will be made.

zhengyu.gu@sun.com
Comment 11 Warren E. Downs 2001-07-17 13:20:26 PDT
There is a major problem with using the user agent string for the Java plugin,
if you wish to access sites which purposely restrict themselves to allowing only
IE clients, based on the user agent string containing Mozilla/4.0.

In order to access some of those sites, the user agent must say Mozilla/4.0, but
in order to use the Java plugin, the user agent must say Mozilla/5.0.  What if a
IE-requiring site also requires Java?  We then have a catch-22 situation, in
which Mozilla users won't be able to access the site.

Please suggest another workaround if you truely don't intend to fix this
problem.
Comment 12 Warren E. Downs 2001-07-17 13:22:21 PDT
There is a major problem with using the user agent string for the Java plugin,
if you wish to access sites which purposely restrict themselves to allowing only
IE clients, based on the user agent string containing Mozilla/4.0.

In order to access some of those sites, the user agent must say Mozilla/4.0, but
in order to use the Java plugin, the user agent must say Mozilla/5.0.  What if a
IE-requiring site also requires Java?  We then have a catch-22 situation, in
which Mozilla users won't be able to access the site.

I know the site shouldn't depend on such things, but Mozilla needs to be
flexible.  If it is to compete with IE, it needs to be able to exactly emulate
IE's behavior.  Please suggest another workaround if you truely don't intend to
fix this problem.

Comment 13 Jacek Piskozub 2001-07-17 13:45:45 PDT
This bug certainly blocks RFE bug 46029. Unless we stop using Sun Java :-(

Marking the block.
Comment 14 basic 2001-07-17 19:37:45 PDT
which part of the user agent string is used? Mozilla/5.0 ?  Gecko/20010713?

If it is just the first part maybe the plugin can use
navigator.appVersion/navigator.appName ? If it is the Second maybe
navigator.product/navigator.productSub ?
Comment 15 Warren E. Downs 2001-07-17 20:01:47 PDT
As many browsers now emulate the original Mozilla by passing Mozilla/4.0 at the
start of the user agent string, then tacking on their own information at the
end, it seems like Mozilla 5.0 should do the same.  That is, it should claim to
be Mozilla/4.0 but add a 5.0 designation later on.

In retrospect, the whole user-agent string idea was a bad one, as it encouraged
sites to cater to specific browsers rather than developing a common standard. 
But now, we're stuck with it, and we have to work within the system that has
evolved to maintain compatibility.

Based on this reasoning, Mozilla should have a variable the Java plugin can use
to get the *true* version string, regardless of what value is spoofed for
various web sites.
Comment 16 edburns 2001-07-18 12:01:14 PDT
This is in Java Plugin Group's realm.  Removing me from CC.
Comment 17 Boris Zbarsky [:bz] (TPAC) 2001-07-30 09:53:13 PDT
*** Bug 92775 has been marked as a duplicate of this bug. ***
Comment 18 Daniel Veditz [:dveditz] 2001-08-01 17:39:21 PDT
Whether or not the Sun folks want to block IE from using their plugin, the crash
in GKCONTENT.DLL is in Mozilla code. We've got to handle that condition; after
that users can beat on Sun if they don't like having to choose between Java and
UA spoofing.
Comment 19 timeless 2001-08-02 01:26:32 PDT
early thoughts:
bc: 2001-06-25 16:13 and 2001-07-17 12:54.
How exactly does the java plugin get the useragent? and why does it use that 
instead of some sane element?

after thoughts:
Ok, I think OJI uses the plugin host to get the useragent, so what i'm going to 
try to do (hopefully w/ gagan and gerv's blessing) is make the useragent its 
own class/interface and make http and plugins both clients of it.  I'll 
actually work on this in some other bug... more later...
Comment 20 shrirang khanzode 2001-08-13 11:34:36 PDT
SPAM: reassigning all OJI bugs to new OJI QA, pmac ( 227 bugs)
Comment 21 Ben Bucksch (:BenB) 2001-08-15 04:48:22 PDT
timeless, I don't understand. The UA string we report to sites is completely
different (exactly *because* it may be faked - faking UA string is not a new
idea) from the UA recognition you might use inside the application or native
plugins. You cannot reuse the same code.
Comment 22 timeless 2001-08-15 05:17:48 PDT
ben; i'd be moving the useragent stuff into its own class, and add a method to 
get real useragent.  http would not use that method, plugin host would.  The 
overall move was ok w/ gagan. -- i should just do it instead of talking about 
it.
Comment 23 Matthias Versen [:Matti] 2001-08-17 09:48:48 PDT
*** Bug 95786 has been marked as a duplicate of this bug. ***
Comment 24 Matthias Versen [:Matti] 2001-08-20 08:00:41 PDT
*** Bug 95786 has been marked as a duplicate of this bug. ***
Comment 25 Jussi-Pekka Mantere 2001-08-24 16:18:51 PDT
Removing nsenterprise nomination.
Comment 26 Matthias Versen [:Matti] 2001-08-30 08:08:31 PDT
*** Bug 97596 has been marked as a duplicate of this bug. ***
Comment 27 CJ Kucera 2001-09-27 12:31:09 PDT
It's been mentioned here that this blocks bug 46029 . . .  Wouldn't 46029
actually fix this bug?  You'd have an "internal" useragent that all plugins, etc
would have access to, but then on a per-site basis Mozilla would report itself
as different browsers.  46029's actually about developing a GUI for this, but
I'd be just as happy to have the backend stuff in place, similar to how you can
turn off javascript on a per-site basis.
Comment 28 CJ Kucera 2001-09-27 12:58:41 PDT
Ummmm, I suppose that I really should have read bug 46029 more carefully; it's
not about having site-based useragents at all.  I couldn't find a bug dealing
with that (hopefully I looked hard enough), so I just submitted bug 101990. 
Apologies for the spam!
Comment 29 Ben Bucksch (:BenB) 2001-09-27 13:28:35 PDT
> You'd have an "internal" useragent that all plugins, etc
> would have access to, but then on a per-site basis Mozilla would report itself
> as different browsers.  46029's actually about developing a GUI for this


No, bug 46029 is about a GUI for a global pref, not a per-site pref. Per-site
prefs (or any backend work) are outside its scope.
Comment 30 Jacek Piskozub 2001-09-27 13:41:26 PDT
Shouldn't this bug be renamed to something like "Separate the real useragent
(seen by pug-ins) from a user controlled one sent to HTTP server"? This isthe
only way to solve this bug anyway (as Sun will not change its Java code).

The component and owner be changed as well. It is no longer a Java bug. Any
propositions?
Comment 31 CJ Kucera 2001-09-27 15:40:52 PDT
Okay, as for the actual seperation of Useragents (what the plugin sees versus
what webpages see), I created bug 102042, and I can start to look at that (but
I've never actually coded in Mozilla before, so if someone's got more experience
and feels like it . . .)  I'm not going to mark this bug as depending on bug
102042, though, because really Mozilla should handle that error much more
gracefully, which I think is more what this bug is all about.

Regardless of what kind of user agent the plugins are getting, if they error out
they should probably just be disabled, rather than causing a whole browser crash.
Comment 32 Matthias Versen [:Matti] 2001-10-18 14:15:57 PDT
*** Bug 105259 has been marked as a duplicate of this bug. ***
Comment 33 Alexander Zuev 2001-10-25 06:54:07 PDT
The simple and quick solution is to add method to nsIHttpProtocolHandler that 
returns system UserAgent string and to use it in nsPluginHostImpl::UserAgent(). 
As i checked, this fixes problem with Java Plug-in and not breaks any 
functionality. I think, that passing overrided UserAgent string to plug-ins is 
not a good idea, because as written in Netscape Plug-in API Reference "You can 
use this information to verify that the expected browser is in use, or you can 
use it in combination with NPN_Version to supply different code for different 
versions of Netscape browsers."
Comment 34 Alexander Zuev 2001-10-25 06:55:41 PDT
Created attachment 55053 [details] [diff] [review]
Possible fix, #1
Comment 35 Alexander Zuev 2001-10-25 06:56:18 PDT
Created attachment 55054 [details] [diff] [review]
Possible fix, part 2
Comment 36 Alexander Zuev 2001-10-25 06:56:48 PDT
Created attachment 55055 [details] [diff] [review]
Possible fix, part 3
Comment 37 Alexander Zuev 2001-10-25 06:57:12 PDT
Created attachment 55057 [details] [diff] [review]
Possible fix, part 4
Comment 38 timeless 2001-10-25 08:05:24 PDT
I'd prefer the alternative. lemme spend my morning on it.
Comment 39 Boris Zbarsky [:bz] (TPAC) 2001-10-25 10:49:58 PDT
*** Bug 106727 has been marked as a duplicate of this bug. ***
Comment 40 Matthias Versen [:Matti] 2001-11-21 14:47:14 PST
*** Bug 111281 has been marked as a duplicate of this bug. ***
Comment 41 Christopher Aillon (sabbatical, not receiving bugmail) 2002-01-02 05:33:32 PST
*** Bug 117705 has been marked as a duplicate of this bug. ***
Comment 42 Dan Mellem 2002-01-25 19:45:34 PST
On Windows 2000 the Java error appears behind the splash screen so I can't read 
the error. Fixing the crash should resolve this but if the plugin presents a 
dialog box it's important the dialog isn't obscured. Incidentally, is there a 
way to disable the splash screen to view the error such as the -splash option in 
Xwindows?
Thanks.
Comment 43 timeless 2002-01-26 14:58:21 PST
try -nosplash/-quiet
Comment 44 Igor Nekrestyanov 2002-01-28 04:07:19 PST
timeless: what about alternative solution for this bug?
          Or may be we can go with Alexander's one?
Comment 45 timeless 2002-01-28 18:09:01 PST
the correct thing imo is to move the useragent generator out of http.  to allow 
for user manipulation, each caller would provide their class-id so that the 
user could configure forgeries on a per class basis.

http and oji would then get the useragentservice and ask for a useragent, each 
would provide a class-id, and the http class-id would be more likely to result 
in a forged useragent than the oji class-id.
Comment 46 Igor Nekrestyanov 2002-02-08 02:49:51 PST
Alexander Zuev is no longer working on OJI.
-> Joe
Comment 47 Igor Nekrestyanov 2002-02-23 10:38:09 PST
Will be fixed on mozilla side 
  -> removing obsolete keyword 
Comment 48 Igor Nekrestyanov 2002-03-19 10:34:01 PST
This one is important.
Let's try to fix it by 1.0
Comment 49 David Illsley 2002-04-08 13:55:31 PDT
*** Bug 134779 has been marked as a duplicate of this bug. ***
Comment 50 Boris Zbarsky [:bz] (TPAC) 2002-04-25 22:22:47 PDT
*** Bug 140215 has been marked as a duplicate of this bug. ***
Comment 51 Boris Zbarsky [:bz] (TPAC) 2002-04-28 15:28:27 PDT
*** Bug 140791 has been marked as a duplicate of this bug. ***
Comment 52 David Orriss Jr 2002-05-03 10:07:00 PDT
This bug seemed to have been fixed for .99 but it's broken again as of 1.0 RC1

Comment 53 Matthias Versen [:Matti] 2002-05-21 23:44:47 PDT
*** Bug 146093 has been marked as a duplicate of this bug. ***
Comment 54 John S. Musarra 2002-05-31 16:58:20 PDT
I just experienced this bug, in both RC3 and a nightly (2002053006), on Win98SE
using JRE 1.4. Crashed upon startup, with the same error message.
Talkback IDs:
TB6879909X
TB6879883M
TB6879841H
TB6879798M

I worked around it by renaming the Progra~1/Java directory. (disabling Java in
the process but what good does it do me without a browser?)
Comment 55 M.J.G. 2002-06-07 00:36:18 PDT
Bug still exists in Mozilla 1.0 (Linux Seamonkey)

WORKAROUND:

JRE checks UA string only at first initialization. Make it happy with a
Mozilla/5 UA string, and change the UA string afterwards using, e.g., uabar from

http://uabar.mozdev.org

Then you can use Java with an arbitrary UA string.
Just make sure to reset the UA string before you close Mozilla, or you will
shoot yourself in your foor the next time you (try to) start it up.

[Maybe someone can put this workaround in the user doc, I know it doesn't quite
belong here.]
Comment 56 Peter Lubczynski 2002-06-07 09:22:30 PDT
Created attachment 86806 [details]
example showing how to change UA with Javascript through HTML

Here's some script and markup I put together that allows changing the UA from
an HTML from. Be sure you grant UniversalXPConnect privileges.
Comment 57 Peter Lubczynski 2002-06-07 09:46:54 PDT
Comment on attachment 86806 [details]
example showing how to change UA with Javascript through HTML

woops...forgot to say you had to save it locally first :)
Comment 58 Sebastian Biallas 2002-09-08 04:05:52 PDT
*** Bug 167359 has been marked as a duplicate of this bug. ***
Comment 59 Ian Neal 2002-09-08 05:05:45 PDT
If you look at bug 106727 and bug 167359 which were duped against this bug, the
UA string also causes a problem with mozilla starting on Linux. I'm going to
reopen bug 106727 and dupe 167359 against that.
Comment 60 Matthias Versen [:Matti] 2002-09-09 15:36:48 PDT
*** Bug 106727 has been marked as a duplicate of this bug. ***
Comment 61 Matthias Versen [:Matti] 2002-09-09 15:37:31 PDT
*** Bug 167593 has been marked as a duplicate of this bug. ***
Comment 62 Ere Maijala (slow) 2002-10-08 07:25:44 PDT
*** Bug 173248 has been marked as a duplicate of this bug. ***
Comment 63 Patty Mac 2002-10-18 11:25:00 PDT
Chris Petersen is a new QA contact for oji component. His email is:
petersen@netscape.com
Comment 64 Patty Mac 2002-10-18 12:16:45 PDT
reassign to joe chou
Comment 65 Matthias Versen [:Matti] 2002-10-21 13:51:41 PDT
*** Bug 175247 has been marked as a duplicate of this bug. ***
Comment 66 Olivier Cahagne 2002-12-06 06:29:51 PST
*** Bug 183900 has been marked as a duplicate of this bug. ***
Comment 67 R.K.Aa. 2002-12-20 00:22:14 PST
*** Bug 186240 has been marked as a duplicate of this bug. ***
Comment 68 Markus 2002-12-20 21:30:28 PST
My bug 186240 is definitively a dup, but brought some propably new aspects:
.
When using a "user.js" to change prefs with former releases of Mozilla (before
1.0/like used to build NS 6.2.3) no entries were copied to the "prefs.js" and no
errorneus messages came up when using JVM 1.3.x/1.4.x.
Now since upgrading to Mozilla 1.1/1.2.1 some prefs (including UA-override and
others) are automatically copied(!) into "pref.js" upon starting with a
"user.js" aside... and the hazzle begins. 
Just removing any "user.js" doesn't fix the problem until you remove the copied
entries in your "prefs.js", too - manually!The formerly kind of overriding prefs
with "user.js" didn't lead the Sun-JVM to the faked value.

Idea#1:
As the JVM-plugin is initialized during startup, simply delay the "override"
until everything like the Sun-JVM has come up and perform this change afterwards.

Idea#2:
Ignore any prefs like that and add a "UA-manager" similiar to the
cookie-management (may propably share routines) including a general mail-setting
and a "per site UA responder" providing an universal value and single
site-settings. By this pages of "handicapped Webmasters" will stay accessible...

A bit more explanatory (see comment added today):
http://bugzilla.mozilla.org/show_bug.cgi?id=186240
Comment 69 Olivier Cahagne 2002-12-27 10:34:26 PST
*** Bug 186913 has been marked as a duplicate of this bug. ***
Comment 70 Torben 2003-01-13 05:13:22 PST
*** Bug 170025 has been marked as a duplicate of this bug. ***
Comment 71 Peter Lubczynski 2003-03-11 10:15:21 PST
--->default owner
Comment 72 Peter Lubczynski 2003-03-11 10:16:54 PST
*** Bug 196842 has been marked as a duplicate of this bug. ***
Comment 73 WD 2003-04-15 12:07:25 PDT
*** Bug 202134 has been marked as a duplicate of this bug. ***
Comment 74 Matthias Versen [:Matti] 2003-05-26 00:17:50 PDT
*** Bug 200968 has been marked as a duplicate of this bug. ***
Comment 75 thebeastwitheyesthatstared 2003-06-01 05:24:50 PDT
is this still happening with more recent software versions? (bug cleaning)
Comment 76 James Rome 2003-06-01 12:45:22 PDT
It doesn't crash, but still gives the error about the plugin being wrong.
Comment 77 Joshua Xia 2003-06-26 21:55:29 PDT
after set useragent to random string by using peter 's html (javascript)

on solaris, JPI report the following error and mozilla can't boot:

INTERNAL ERROR on Browser End: Expected a version > 5! Version = 0

System error?:: No such file or directory

JPI use useragent string to decide the mozilla 's version and boot corresponding
service? for example: MNetscape4BrowserService or MNetscape6BrowserService?
Comment 78 Joshua Xia 2003-06-26 22:08:53 PDT
Xiaobin, 
I found that the set useragent javascript don't work on Netscape 4.7x, should
JPI set default browser version >= 5? so that JPI recognise browser as "netscape
>= 5" even though useragent is modified?

Comment 79 Richard Thomas 2003-07-18 12:38:13 PDT
*** Bug 213106 has been marked as a duplicate of this bug. ***
Comment 80 Alexander Opitz 2003-08-04 02:58:21 PDT
*** Bug 164823 has been marked as a duplicate of this bug. ***
Comment 81 Matthew van Eerde 2003-11-07 09:00:22 PST
I like the idea of being able to report my UA to certain sites as a fake IE -
then I'd finally be able to stop using IE altogether (I currently use it for
support.microsoft.com)
Comment 82 Joshua Xia 2003-11-24 19:15:21 PST
->kyle
Comment 83 Kyle Yuan 2003-12-03 02:41:25 PST
Xiaobin, should we consider this bug into our new design that get the mozilla
version through a certain interface method instead of analyzing the user-agent
string?
Comment 84 Jack Lu 2003-12-03 10:07:47 PST
Kyle,

Can you verify whether this bug is still valid in JRE 1.5? 
Comment 85 Kyle Yuan 2003-12-03 17:55:12 PST
in JRE 1.5, java plugin does not complain that you are using the wrong plugin,
and does not crash mozilla any more. But I get this exception when running a
simplest applet:
java.lang.NullPointerException
	at
com.sun.deploy.net.proxy.WNetscape4ProxyConfig.getNSVersion(WNetscape4ProxyConfig.java:72)
	at
com.sun.deploy.net.proxy.WNetscape4ProxyConfig.getBrowserProxyInfo(WNetscape4ProxyConfig.java:29)
	at com.sun.deploy.net.proxy.DynamicProxyManager.reset(DynamicProxyManager.java:133)
	at com.sun.deploy.net.proxy.DeployProxySelector.reset(DeployProxySelector.java:60)
	at sun.plugin.AppletViewer.initEnvironment(AppletViewer.java:460)

I think the JPI module still has no idea about what version of mozilla it is
working with.
Comment 86 Kyle Yuan 2004-02-02 21:26:17 PST
Created attachment 140482 [details] [diff] [review]
re-assemble useragent string instead of getting it through nsIHttpProtocolHandler::GetUserAgent

this means some duplicate work but can avoid api change.
Comment 87 Michael Lefevre 2004-02-03 16:59:14 PST
*** Bug 187402 has been marked as a duplicate of this bug. ***
Comment 88 Darin Fisher 2004-02-03 21:34:04 PST
hmm... nsIHttpProtocolHandler is not FROZEN.  perhaps we should modify it to
provide a getter for the real/default/official useragent string.

actually, i wonder if this problem exists elsewhere.  should the useragent
override really affect what the DOM reports?
Comment 89 Kyle Yuan 2004-02-03 22:54:17 PST
It will be better if we can change the api in nsIHttpProtocolHandler, that is
also what attachment 55053 [details] [diff] [review] - 55057 proposed. I'm going to make a new patch to
combine them together.

As far as I can tell, nsPluginHostImpl::UserAgent is the only place that needs
the original useragent string.
Comment 90 Kyle Yuan 2004-02-04 02:07:11 PST
Created attachment 140589 [details] [diff] [review]
a new method to get "system" useragent

It's better than re-create the wheel if we can change the
nsIHttpProtocolHandler api.
Comment 91 Kyle Yuan 2004-02-04 02:12:26 PST
Comment on attachment 140589 [details] [diff] [review]
a new method to get "system" useragent

darin, how about this one?
Comment 92 Ben Bucksch (:BenB) 2004-02-04 08:45:54 PST
Don't both patches bear the risk that the original UA string leaks to the
network, now or in the future? Apart from that, they make the code more complex.

IIRC, the problem was that the Java plugin retrieved the Mozilla version by the
UA string and made internal decisions based on that. Instead of using the UA
string, which is only intended for *remote* sites, why not use other, internal
means to determine the real prooduct version and use that directly and treat the
UA string as a long, unparsable string?
Comment 93 Darin Fisher 2004-02-04 23:31:52 PST
Ben makes a good point.  Though I suspect the answer is that this depends on a
"frozen" binary contract of some sort between the browser and the java plugin.
But, heck... I might be wrong ;-)
Comment 94 Kyle Yuan 2004-02-05 00:03:30 PST
Comment on attachment 140589 [details] [diff] [review]
a new method to get "system" useragent

Yes, useragent string is the only way for java plugin to obtain the agent
information of all supported browsers - Mozilla, IE, NS4.x, NS6&7.
But anyway, this is not in the top priority at all.
Comment 95 Jason Barnabe (np) 2004-02-10 21:02:55 PST
*** Bug 233581 has been marked as a duplicate of this bug. ***
Comment 96 José Jeria 2004-02-12 09:40:55 PST
*** Bug 234041 has been marked as a duplicate of this bug. ***
Comment 97 Bill Mason 2004-03-03 22:58:02 PST
*** Bug 236430 has been marked as a duplicate of this bug. ***
Comment 98 mozilla.org 2004-03-23 00:53:20 PST
*** Bug 238244 has been marked as a duplicate of this bug. ***
Comment 99 mozilla.org 2004-03-23 01:09:48 PST
I don't think this is a Java bug.
It could easily fixed: Just load the different UA after the initialisation of
the plugins, because switching the UA later works. I don't know if Java uses
this UA later?
Comment 100 Iain Gray 2004-03-31 15:04:18 PST
1st time with this, using Firebird 0.7 and Mozilla 1.5 spoofing ie6 WinXP, on
site requiring JavaVM (version 1.4.2 installed) both browsers crash with the
following message:

Plugin: unexpected work request from child
INTERNAL ERROR on Browser End: Code = f60006
System error?:: Sucess

Whereby browser has shutdown.
Comment 101 Bill Mason 2004-05-01 21:02:54 PDT
*** Bug 242306 has been marked as a duplicate of this bug. ***
Comment 102 Michael Prager 2004-06-07 06:03:01 PDT
Still experiancing this bug with Mozilla 1.7rc1 and Java 1.4.1 under Linux: 
 
No running windows found 
INTERNAL ERROR on Browser End: Expected a version > 5! Version = 4 
 
System error?:: Datei oder Verzeichnis nicht gefunden 
 
Comment 103 Bill Mason 2004-09-09 00:02:52 PDT
*** Bug 258559 has been marked as a duplicate of this bug. ***
Comment 104 Corey Small 2004-09-10 11:49:50 PDT
Created attachment 158454 [details]
Message window when opening FireFox, while defalt set to IE.

FireFox never opens, but maintains 99% CPU usage.
FireFox Nightly build 1.0.
Comment 105 (Anonymous) 2004-09-21 12:31:35 PDT
(In reply to comment #104)
> Created an attachment (id=158454)
> Message window when opening FireFox, while defalt set to IE.
> 
> FireFox never opens, but maintains 99% CPU usage.
> FireFox Nightly build 1.0.

can confirm this with firefox v1.0 PR
(Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10)
Comment 106 José Jeria 2004-09-26 00:11:47 PDT
*** Bug 261592 has been marked as a duplicate of this bug. ***
Comment 107 Tuukka Tolvanen (sp3000) 2004-09-26 15:28:02 PDT
*** Bug 261706 has been marked as a duplicate of this bug. ***
Comment 108 Tuukka Tolvanen (sp3000) 2004-09-26 15:28:51 PDT
*** Bug 261317 has been marked as a duplicate of this bug. ***
Comment 109 Matthias Versen [:Matti] 2004-11-15 05:50:24 PST
*** Bug 269948 has been marked as a duplicate of this bug. ***
Comment 110 Don Hughes 2004-11-15 06:46:49 PST
With the current implementation after the JS popup the browser hangs and does 
not finish initializing and I am prevented from taking any corrective action, 
and in many cases even browsing for a solution.  This condition should be 
trapped, and the browser should continue to load without Java.  I block js on 
most sites anyway, and would MUCH rather have a Java-less browser than no 
browser.
Comment 111 Kyle Yuan 2004-11-17 22:32:38 PST
*** Bug 269289 has been marked as a duplicate of this bug. ***
Comment 112 Nickolay_Ponomarev 2004-11-18 14:07:52 PST
*** Bug 270652 has been marked as a duplicate of this bug. ***
Comment 113 Nickolay_Ponomarev 2004-11-18 14:08:32 PST
*** Bug 249594 has been marked as a duplicate of this bug. ***
Comment 114 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-21 13:57:48 PST
*** Bug 270939 has been marked as a duplicate of this bug. ***
Comment 115 OstGote! 2004-11-22 00:57:23 PST
*** Bug 271006 has been marked as a duplicate of this bug. ***
Comment 116 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-27 15:23:59 PST
*** Bug 272049 has been marked as a duplicate of this bug. ***
Comment 117 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-27 15:24:43 PST
*** Bug 172724 has been marked as a duplicate of this bug. ***
Comment 118 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-27 15:25:19 PST
*** Bug 272047 has been marked as a duplicate of this bug. ***
Comment 119 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-27 15:25:32 PST
*** Bug 171550 has been marked as a duplicate of this bug. ***
Comment 120 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-27 15:31:10 PST
*** Bug 196311 has been marked as a duplicate of this bug. ***
Comment 121 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-27 15:33:43 PST
*** Bug 175500 has been marked as a duplicate of this bug. ***
Comment 122 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-27 15:34:59 PST
Ugh.
Very sorry about all the spam.
Comment 123 James Laver 2004-11-27 15:38:46 PST
User agent switcher plugin for firefox 1.0 generates same problem.

suggest the plugin be removed until patched? Is there no way to uninstall the
java plugin manually?
Comment 124 James Laver 2004-11-27 15:40:29 PST
Appendix for above : URL of said extension :
https://update.mozilla.org/extensions/moreinfo.php?application=firefox&id=59&vid=617
Comment 125 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-27 15:52:36 PST
The extension just facilitates the change made to the preferences file. If it's
causing problems, either don't use the extension or don't use java.

The Java plugin doesn't support UA spoofing, so this error message will not be
gone until Sun fixes their Java plugin (which they have indicated they don't
want to do, see comment 10). The fix that needs to be made in this bug is better
handling of the plugin output by Mozilla, so that there is no crash.

Besides, people *really* shouldn't be changing their useragent string for
everyday browsing.
Comment 126 James Laver 2004-11-27 16:29:51 PST
Created attachment 167225 [details]
Manual removal instructions for those not following the comment trail

Step by step instructions to remove the user agent switcher extension and
change the user agent string back to normal
Comment 127 Cameron Simpson 2004-11-27 16:41:56 PST
(In reply to comment #125) 
> Besides, people *really* shouldn't be changing their useragent string for
> everyday browsing.

Ah, there's that word again. "should".

Sometimes these hacks are necessary. For example, until quite recently I had to
lie about the User-Agent to my online bank in order to be offered its menus
for transfers and so forth. Had they been java based I'd have been forced
into some inferior browser.

Now, it's fine to say "they should fix their site". I even took this route in
as much as reporting a description of the problem to them. However, like _many_
web sites, their underlying infrastructure is supplied by a third party and
turnaround for a fix and then redeployment after QA is quite long if it even
happens.

So it's a pragmatic fact the people do need to lie about their User-Agent from
time to time.
Comment 128 Christian :Biesinger (don't email me, ping me on IRC) 2004-11-27 16:43:53 PST
(In reply to comment #125)
> The fix that needs to be made in this bug is better
> handling of the plugin output by Mozilla, so that there is no crash.

Well, that assumes that is possible... If the java plugin crashes, there is
nothing mozilla can do about that; except running plugins in an own process,
which is somewhat hard to do. (bug 156493)
Comment 129 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-27 16:48:10 PST
(In reply to comment #127)
> Sometimes these hacks are necessary.

That's why I said "for everyday browsing". People tend to change it to IE and
leave it that way. That's not necessary and hurts efforts to promote coding for
alternative browsers.

(In reply to comment #128)
> Well, that assumes that is possible... If the java plugin crashes, there is
> nothing mozilla can do about that; except running plugins in an own process,
> which is somewhat hard to do. (bug 156493)

I was just referring to comment 18.
Comment 130 mozilla.org 2004-11-27 17:21:50 PST
What is wrong with this:

1. load mozilla, set the user-agent to default
2. load all plugins
3. set the user-agent to the user's preference.

if you start mozilla/firefox and change the ua-string later everything works as
expected, so why don't automize it?
Comment 131 James Laver 2004-11-27 17:25:57 PST
(In reply to comment #130)
> What is wrong with this:
> 
> 1. load mozilla, set the user-agent to default
> 2. load all plugins
> 3. set the user-agent to the user's preference.
> 
> if you start mozilla/firefox and change the ua-string later everything works as
> expected, so why don't automize it?

because firefox cant be started on account of it shutting down before the GUI is
loaded
Comment 132 Jacek Piskozub 2004-11-28 00:05:05 PST
What about the comment #19 idea by timeless? In short to tell different UA
strings to html and plugins (plugins would always get the true one).
Comment 133 James Laver 2004-11-28 04:47:51 PST
(In reply to comment #132)
> What about the comment #19 idea by timeless? In short to tell different UA
> strings to html and plugins (plugins would always get the true one).

I think that could work, but how will it be done?

From what I can see, mozilla only loads the plugin once, so the UA will only be
checked once. if we changed the UA only after the java plugin had been loaded,
that could be a possible fix.
Comment 134 timeless 2004-11-28 11:03:59 PST
hyperoneggybread@hotmail.com, good for you, unfortunately you're wrong. plugins
can be reloaded in a few ways, including visiting about;plugins and loading
javascript:navigator.plugins.reload(true), which some web pages do.
Comment 135 James Laver 2004-11-28 12:06:55 PST
(In reply to comment #134)
> hyperoneggybread@hotmail.com, good for you, unfortunately you're wrong. plugins
> can be reloaded in a few ways, including visiting about;plugins and loading
> javascript:navigator.plugins.reload(true), which some web pages do.


well thats easy enough to get round, just change the section of code that loads
the plugins (which I presume was what comment #18 was about). then it would set
the user string to the default before loading it, then change it back
afterwards. I dont have the code in front of me at the moment, so i will have a
look when i see it.
Comment 136 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-11-30 23:44:21 PST
*** Bug 272539 has been marked as a duplicate of this bug. ***
Comment 137 Todd 2004-12-03 16:05:09 PST
Hi All,

     I have been doing a lot of Firefox upgrades.  I have to hand remove

user_pref("general.useragent.override", "Mozilla/4.0 (compatible; MSIE 6.0;
Windows NT 5.1)");

from prefs.js to get them to run.  What a pain!  Would you guy consider 
fixing this more quickly to assist those of us in the field.

Many thanks,
--Tony
Comment 138 James Laver 2004-12-06 15:30:53 PST
(In reply to comment #137)

I've put removal instructions in the attachments section if anyone is interested
in that, like you.

What I will do in a minute is to write some code to automate that removal as a
temporary fix, but im also trying to patch this bug.

Bear with us, we're volunteers, and we're going as fast as we can.
Comment 139 Bill Mason 2004-12-20 23:36:11 PST
*** Bug 275501 has been marked as a duplicate of this bug. ***
Comment 140 Phil Ringnalda (:philor) 2005-01-17 10:39:49 PST
*** Bug 278734 has been marked as a duplicate of this bug. ***
Comment 141 Keith Tyler 2005-03-03 10:26:55 PST
I'd like to add a note that, to my consternation, -safe-mode did not avoid 
this problem. One would think that Safe Mode would at least let the browser 
open. But the same error comes up.

BTW when this happens, Firefox remains open as a process, hogging resources, 
but there is no browser window. The browser process has to be terminated via 
taskman. Also, while this process is alive, IE won't properly start.

(WinXP/FF1.0)
Comment 142 R.K.Aa. 2005-03-04 13:31:49 PST
*** Bug 284681 has been marked as a duplicate of this bug. ***
Comment 143 alanjstr 2005-03-12 17:26:01 PST
*** Bug 285753 has been marked as a duplicate of this bug. ***
Comment 144 Robert Parenton 2005-03-14 21:54:57 PST
Comment #141, safe mode is for disabling extensions, not plugins, which is what
Java is.
Comment 145 James Laver 2005-03-17 13:00:57 PST
i think the point of safe mode was to disable the UA switcher extension from
starting.

but the override in the firefox preferences sscript needs to be modified

check the attachment i posted for instructions to do that:
https://bugzilla.mozilla.org/attachment.cgi?id=167225
Comment 146 Kyle Yuan 2005-04-14 23:58:24 PDT
Filed bug 6212945 in Sun bug database to track this issue.
Comment 147 Kyle Yuan 2005-06-03 21:28:01 PDT
mass reassign my bugs to Pete Zha.
Comment 148 Joe 2005-08-31 13:54:51 PDT
has anyone been able to fix this bug? Please Help!!
Comment 149 timeless 2005-08-31 18:00:11 PDT
joeballer@gmail.com: please don't spam bugs with silly questions like that one. 
you're perfectly able to read the bug which clearly has no resolution 
(especially not fixed), feel free to click on status/resolution to read 
https://bugzilla.mozilla.org/page.cgi?id=fields.html

there's really no good way for a mozilla dev to fix this bug, it should be 
fixed by a sun java plugin developer (we don't have their source code).
Comment 150 (Anonymous) 2005-09-01 06:41:39 PDT
if firefox crashes its suns fault?
i don't think so

there should be at least an error message a warning or whatnot

another thing i dont understand is why we have this cute extension manager but
nothing like this for plugins. as workaround java could be disabled when the
user-agent string is changed
Comment 151 timeless 2005-09-01 11:08:33 PDT
hotbot@gmx.de: people work on the cute things they want to work on. there's a
bug for a plugin manager and you're welcome to work on it. this is not that bug.

as for plugins and extensions causing gecko to quit. if any in process code
calls abort() or exit() or terminatethread or whatever, gecko's dead. this is
not gecko's fault. if you install an extension or plugin on your system, you
authorize it to terrorize gecko and you trust it not to do so. native code is
trusted, it is not managed. unlike jvm bytecode which a jvm manages.

for most of java's plugin life, when it disagrees w/ the useragent, it *quits*
gecko, it doesn't cause a crash. if you guys actually find it triggering talkbac
(which would mean it's crashing), then file a new bug with the talkback incident
id, and i'll see about getting that crash resolved.

note that it's fairly hard to predict the filename for a plugin, so we can't
simply temporarily change the useragent, plus it's unclear when the plugin might
decide to ask for the useragent, so we might still manage to get it set back
forged at the wrong time. note that the disable java option is actually fairly
late, and probably *after* the plugin inits and kills gecko.
Comment 152 Joe 2005-09-02 15:51:38 PDT
start > run > firefox -p

^^ make a new profile and it will be fixed but you will lose your stuff.
Comment 153 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-10-17 13:32:33 PDT
*** Bug 312757 has been marked as a duplicate of this bug. ***
Comment 154 Dorian 2006-02-14 03:41:14 PST
I'm not sure if it's related but, if the user agent string is too long then java crash (or lock the browser). nsPluginHostImpl::UserAgent return a null pointer in that case, and java doesn't like it at all ...
Comment 155 Pete Zha 2006-02-17 01:55:27 PST
mass reassign to Alfred
Comment 156 matt harrison 2006-06-28 10:49:16 PDT
I'm seeing this issue or (bug 238244).  I'm not doing anything with java on the webpage, so I'm not sure if it's related.

Here's my blog post on the issue: http://panela.blog-city.com/take_care_when_emulating_ie_under_firefox.htm

I'm using gentoo so I have am building from source.  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060627 Firefox/1.5.0.4
Comment 157 Imran Khan 2007-01-28 09:36:34 PST

Dear Sir



I am one of the great fan of Mozilla Fire fox 2.0. However whenever i am trying to go online with any mail site like aol.com, hotmail.com or yahoo.com and some other site like www.citibank.co.in it get shut down automatically. I can open the page but it shuts down on each site when i try to login in my account of each side.



I have encountered the same problem couple of months ago and I wrote you an email and then after some time it start working. I dont know that wether you did something or it was done automatically but it was working fine. 



Now again i am facing the same problem and its great problem for me because i don't like any other browser after using Fire fox 2.0. So kindly look into the matter and hope that you will me as soon as possible.


With Regards
Imran Khan
+91 9891 243 273
Skype ID : imran.khan.81 


Comment 158 Gábor Stefanik 2007-03-30 04:44:06 PDT
Although it doesn't really fix the problem, just doesn't crash: If general.useragent.override is set, we should auto-disable the Java plugin. That way, the user gets a message in place of the applet: "User agent spoofing is turned on. Java doesn't work with user agent spoofing.".
Comment 159 Ian Macfarlane 2007-03-31 13:58:00 PDT
A more hackish but lower impact way of doing comment 158 could be to disable the java plugin if the User Agent is set to MSIE.

I'd really rather the Sun guys got it fixed at their end though.
Comment 160 timeless 2007-03-31 16:38:12 PDT
please read comment 151 again (for the first time)

how exactly does one detect the plug-in? it can have any file name and AFAI-understand the act of loading it is what gets us killed.
Comment 161 Ben Bucksch (:BenB) 2007-04-01 05:14:57 PDT
> comment 151

Interesting (and funny). I wonder why, after 6 years, Sun can't at least stop exit()ing Gecko. Can somebody escalate that with them?

> how exactly does one detect the plug-in? it can have any file name

Mimetype? I know Java has a lot - but one could pick one known Java mimetype, map that to filename or internal pluginmanager entry.
Comment 162 timeless 2007-04-01 09:16:10 PDT
not all java plug-ins are Sun. There's IBM, Apple / MRJ, possibly others. What do we do for those? lie too? and again, when? please keep in mind that I don't actually know /when/ or under /what/ conditions the plug-in will decide to exit().
Comment 163 Ben Bucksch (:BenB) 2007-04-01 09:55:34 PDT
> What do we do for those? lie too?

No, do *not* "lie" for any plugins.

But see comment 21 and comment 92 for what I think about such a workaround (give real UA) for a workaround (no way to get browser vendor and version from plugin code) tripping over yet another workaround (fake UA string to get on braindead websites). Esp. today where faking the UA string to get to websites with Mozilla is hardly needed anymore.
Comment 164 timeless 2007-04-01 17:56:48 PDT
aww. forget it. what if someone actually needs to have a plug-in lie to a web site and the plug-in properly asks gecko for how to lie.

this is a rat's nest that i really have no involvement in (ignoring the fact that I actually am spending some non trivial amount of my time dealing w/ other plug-ins). a long time ago I had some attachment to Java. at the present time, my platform doesn't even have Java. in fact, we only have Flash (officially that's flash7, i think).

please just keep the following in mind:
1. darin, gagan (gone), biesi, benb, myself do not have access to the Java code and have no idea when/how[often] it chooses to ask about the user-agent
2. plug-ins can and should be able to ask for the user-agent because they can and should be able to make http requests that mimic those of the browser (that's why the feature is there!)
3. a plug-in *could* if it wanted to access the navigator object and try to get something that lies less often (there's no guarantee the object wouldn't lie, it's in fact quite likely that on a browser I develop sometime between 2001 and 2011 the browser would lie about that object).
4. there's no way to know when a plug-in will choose to ask what the user-agent is (short of reverse engineering it, and again, I have no interest in doing that as Java hasn't been something I've cared about in 5+ years)

comment 94 is kinda key. people should really complain to Sun.

For now, I'm giving this bug to jst. it's his mess, and I quote:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6212945

Bug ID: 	6212945
Votes 	0
Synopsis 	Javaplugin crashed with a spoofed mozilla's useragent string
Category 	java_plugin:plugin
State 	Closed, not a bug
Submit Date 	29-DEC-2004
Description 	

Java plugin easily crashed if the user changed mozilla's useragent string to something else other than the default one. More detail please see:

https://bugzilla.mozilla.org/show_bug.cgi?id=83376

Since the java plugin libraries have already been loaded into memory, java plugin should be able to know which version of browser it is working with. No need borthering [sic] to parse the useragent string to get such information.
 xxxxx@xxxxx  2004-12-29 09:10:20 GMT

 xxxxx@xxxxx  2005-06-09 09:00:06 GMT

it's not a bug on Java plugin side. browser should provide plugin real UA for plugin to work no matter whether UA string is overriden by end users.  it's the contract between browser and plugin. the following document is from Netscape Geoko [sic] Plug-in API reference for NPN_UserAgent()

Description

The user agent is the part of the HTTP header that identifies the browser during transfers. You can use this information to verify that the expected browser is in use, or you can use it in combination with NPN_Version to supply different code for different versions of Netscape browsers.
 xxxxx@xxxxx  2005-06-27 05:34:08 GMT

http://devedge-temp.mozilla.org/library/manuals/2002/plugin/1.0/npn_api19.html
plug-ins!

    NPN_UserAgent

    Returns the browser's user agent field.

    Returns

    A pointer to a buffer that contains the user agent field of the browser.

    Description

    The user agent is the part of the HTTP header that identifies the browser during transfers. You can use this information to verify that the expected browser is in use, or you can use it in combination with NPN_Version to supply different code for different versions of Netscape browsers. 

http://devedge-temp.mozilla.org/library/manuals/2002/plugin/1.0/npn_api20.html#999834
plug-ins!

    NPN_Version

    Returns version information for the Plug-in API.
     
    Description

    The values of the major and minor version numbers of the Plug-in API are determined when the plug-in and the browser are compiled. For example, Plug-in API version 4.03 has a major version number of 4 and a point release number of 3. This function gets the values from the plug-in rather than from the browser.

    A plug-in can use this function to check that the version of the Plug-in API it is using is compatible with the version in use by the browser. This could be part of the initialization process. For more information and an example, see "Getting the Current Version."

    You can use NPN_Version to inquire on version constants (NPVERS constants), which represent particular Communicator features. Once the plug-in obtains a version number, it can inquire on a version constant to find out if the feature it represents exists in this version. For example, the plug-in could inquire on the constant NPVERS_HAS_WINDOWLESS to see if it is running in a version of Communicator that supports windowless functionality. For more information and an example, see "Finding Out if a Feature Exists." For a listing of version constants defined in the Plug-in API, see "Version Feature Constants."

There's a plug-in mailing list. jst is the mozilla representative, he can iron this mess out. IMO Sun should use NPN_Version, NPN_UserAgent is at least ambiguous, it clearly didn't predict this case. These two statements happen to normally be equivalent:
1.    The user agent is the part of the HTTP header that identifies the browser during transfers.
2. You can use this information to verify that the expected browser is in use,....

However, in this fun case, they aren't. NPN has essentially contracted the impossible. part 1 is perfectly clear, and not returning what we do seems to clearly violate it. IMO Sun must use NPN_Version/NPN_GetValue it can simply ask if the host supports XPCOM. That's what it needs to know, and that's how it should get the information it needs.

To determine if a plug-in host is XPCOM, plug-ins should (IMO) use NPN_GetValue
NPNVserviceManager 
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/modules/plugin/base/public/npapi.h&rev=3.14&mark=319#308
introduced for bug 98285

And I think we should document this.
Comment 165 patch_linams 2007-07-11 06:18:25 PDT
Created attachment 271827 [details]
improved User Agent Switcher extension as a workaround (or a bugfix?)

Actually, there is a way to use non-standard user agents with a Java Plug-in. Nothing has to be implemented on the browser's side in hard C++ ;-) 

I implemented a fix for the User Agent Switcher extension which allows you to use any non-standard user agent strings without having to reset them to default at any time and without thinking about Java Plug-ins. I sent the fix to the developer of User Agent Switcher. We shall wait until he uses it in his extension.

In the meantime, you can test it yourself (the improved version of the extension is in the attachment - just for testing!!!)
Comment 166 Ben Bucksch (:BenB) 2007-07-11 16:03:56 PDT
Can you shortly say how you implemented this (the trick used, not necessarily the code) instead of attaching a XPI?
Comment 167 timeless 2007-07-11 21:22:59 PDT
Comment on attachment 271827 [details]
improved User Agent Switcher extension as a workaround (or a bugfix?)

benb, you can read the file, it's pretty easy to do: jar:https://bugzilla.mozilla.org/attachment.cgi?id=271827!/components/nsUASThread.js
Comment 168 patch_linams 2007-07-12 16:22:22 PDT
(In reply to comment #166)
> Can you shortly say how you implemented this (the trick used, not necessarily
> the code) instead of attaching a XPI?
> 

Well, as specified in the contract between a Gecko-based browser and a Java Plug-in the Plug-in always gets the default user agent string when the Plug-in is used. 

The thing is that it needs the user agent string only once when an instance of a Java class is created. Therefore the fixed extension (take a look at the useragentswitcher.js) checks at startup whether a Java Plug-in is installed and if it is the extension will create a new instance of a Java class using the default user agent string. After that is doesn't matter what user agent is selected 'cause the Java Plug-in has already initialized the environment. If no Java Plug-in is installed a separate thread (nsUASThread.js) is used to check at runtime for a newly installed Plug-in. If a new one gets installed the game is the same: an instance of a Java class is created and the environment is initialized.

In other words, at any given time the Java Plug-in is satisfied 'cause it's forced to use the default user agent string exactly once which is all it needs.

Actually, that can be easily implemented somewhere in the browser's code if somebody is ready to do it :-)
Comment 169 patch_linams 2007-07-12 16:37:41 PDT
Created attachment 272087 [details]
An early (not final) version of the fixed extension was attached earlier. Here is the right one :-)

Well, an early version got uploaded. Sorry about that ;-) Please, use the attached version (especially Windows users!!!)
Comment 170 timeless 2007-07-13 02:48:30 PDT
note that the java plug-in can be reloaded at any time, so such a hack really would have to be done by the plug-in host.
Comment 171 patch_linams 2007-07-13 11:20:45 PDT
I agree, it has all the needed methods already. And since Sun won't change its plug-in this could be the solution for all Gecko-based browsers (Phoenix/Firebird/Firefox/Mozilla/Netscape were tested). It's not the most elegant one but it works.
Comment 172 Clemens Eisserer 2007-09-11 13:53:57 PDT
It just my personal opinion but I think this patch has several misconceptions:

- It starts java at gecko-startup, which means it slows down the lading process.
- It bets on the fact that the plugin only once loads the UA-String, ignoring the fact that the plugin can be loaded multiple times (or be unloaded and later reloaded).
- It does not solve the problem.

Sun's plugin source is, although not open-source, accessible for everybody and fixes can be submited to Sun through the jdk-collaboration project.
So "bugs" should be fixed where they occur, not worked arround in other places.

Currently Sun's plugin uses the user-agent string to detect the browser it is running. So, which other straightforward ways do exist to detect gecko reliable without some gecko specific APIs or hacks.
If there is none, then its really not SUN's fault ;)

lg Clemens
Comment 173 Clemens Eisserer 2007-09-11 13:55:23 PDT
since it really does not look like a plugin-problem, why not change NPN_UserAgent() to always return the original user-agent?

lg Clemens
Comment 174 patch_linams 2007-09-18 13:22:58 PDT
> It just my personal opinion but I think this patch has several misconceptions:

Actually, this is a patch for an extension which means you can use the extension or leave it ;-) Or create a better solution and post it here...

> - It starts java at gecko-startup, which means it slows down the lading
> process.

On a modern PC it does not slow down the loading process that much.

> - It bets on the fact that the plugin only once loads the UA-String, ignoring
> the fact that the plugin can be loaded multiple times (or be unloaded and 
> later reloaded).

Please, _really_ test that case yourself and post here the results before drawing any theoretical conclusions.

> - It does not solve the problem.

The improved extension fixes the problem so no crashes can occur. You can label it as a "WORKSFORME* fix.

> since it really does not look like a plugin-problem, why not change
> NPN_UserAgent() to always return the original user-agent?

The answer to that question is too obvious :-)
Comment 175 alanjstr 2008-12-08 16:23:20 PST
Is this still an issue?
Comment 176 Geoff Norton 2009-02-03 21:18:11 PST
This is still an issue.  The Moonlight plugin needs to know wether we're running in FF2 or FF3, and NPN_UserAgent is the only real mechanism in NPAPI to do this.  The documentation clearly states:

The user agent is the part of the HTTP header that identifies the browser during transfers. You can use this information to verify that the expected browser is in use, or you can use it in combination with NPN_Version to supply different code for different versions of Netscape browsers. 

Which is ambiguous at best.  If we cannot use NPN_UserAgent to "verify that the expected browser is in use", we should be adding another API call (NPN_GetRealUserAgent) to NPAPI and push all browser manufacturers to use it.  The current stalemate that exists isn't helping anyone.
Comment 177 timeless 2009-02-04 01:19:49 PST
you should be able to compare NPAPI versions I'm fairly certain 2 and 3 have different versions.

But yes, the documentation is clearly bad. I'd like for us to remove the "you can".
Comment 178 Gábor Stefanik 2009-02-04 06:43:26 PST
Why don't we just always return the original (non-spoofed) user agent in NPN_UserAgent, regardless of what we are sending to websites? Or, perhaps, split general.useragent.override to general.useragent.httpOverride and general.useragent.npapiOverride?
Comment 179 Geoff Norton 2009-02-04 07:25:28 PST
(In reply to comment #177)
> you should be able to compare NPAPI versions I'm fairly certain 2 and 3 have
> different versions.
> 
> But yes, the documentation is clearly bad. I'd like for us to remove the "you
> can".

Checking NPAPI is great and all if we only support Firefox.  Some plugin vendors want to support multiple browsers (like us) and there is value in knowing which actualy browser you are running under so you can dynamically load code which is browser dependent.

Clearly the solution here is:

1: Make NPN_UserAgent return the real agent to the plugin and provide a new api call to get the spoofed agent for making requests.
2: Make NPN_UserAgent return the spoofed agent, and make a new call to get the real agent in NPAPI.

Ideally #1 should be the case since other vendors (like sun) are relying on this behaviour (as it is documented)
Comment 180 Mike Hommey [:glandium] 2009-02-04 08:16:45 PST
> 1: Make NPN_UserAgent return the real agent to the plugin and provide a new api
> call to get the spoofed agent for making requests.

Aren't they supposed to make requests through NPAPI, already? A plugin making requests directly sounds to me like a big issue, as such plugins would probably not follow proxy rules and other such things.
Comment 181 Ben Bucksch (:BenB) 2009-02-04 08:30:36 PST
There is a way to open streams via NPAPI, but not all plugins use it.

Irregardless of which method is used, the spoofed UA must always be used for network communication. There are several use cases for spoofing the UA - some of them (making certain websites work, which us rare these days and discouraged) don't care about it, but others (hiding security details like my browser and version number, which may imply security bugs present) do. Due to the latter, the *real UA must not leak* to the network under any circumstance.

Consequently, the current API NPN_UserAgent() needs to continue to return the spoofed user agent (proposal 2 in comment 179).
There would need to be a new call for the plugin's internal needs to differentiate browsers and adapt their own behaviour.
Ideally, the user agent string would not be used for that, for the same reasons as user agent use is discouraged in websites, but I understand there's not always another way.
Comment 182 Geoff Norton 2009-02-04 08:47:03 PST
(In reply to comment #180)
> > 1: Make NPN_UserAgent return the real agent to the plugin and provide a new api
> > call to get the spoofed agent for making requests.
> 
> Aren't they supposed to make requests through NPAPI, already? A plugin making
> requests directly sounds to me like a big issue, as such plugins would probably
> not follow proxy rules and other such things.

In an ideal world this is true.  In the real world NPAPI doesn't have enough control over things like headers to be useful for all use cases.

(In reply to comment #181)
> There is a way to open streams via NPAPI, but not all plugins use it.
> 
> Irregardless of which method is used, the spoofed UA must always be used for
> network communication. There are several use cases for spoofing the UA - some
> of them (making certain websites work, which us rare these days and
> discouraged) don't care about it, but others (hiding security details like my
> browser and version number, which may imply security bugs present) do. Due to
> the latter, the *real UA must not leak* to the network under any circumstance.
>

Agreed that the UA must not leak.

> Consequently, the current API NPN_UserAgent() needs to continue to return the
> spoofed user agent (proposal 2 in comment 179).
> There would need to be a new call for the plugin's internal needs to
> differentiate browsers and adapt their own behaviour.
> Ideally, the user agent string would not be used for that, for the same reasons
> as user agent use is discouraged in websites, but I understand there's not
> always another way.

Disagree here.  NPN_UserAgent has existed since before ua spoofing, and documents itself as being how we identify the browser.  If you want to let pluings make their own network streams and not leak the UA, add a NEW NPAPI call for this behaviour.

I agree that ideally browser identification wouldn't use the UA to plugins, but the api is already there and documented as behaving as such.
Comment 183 Gábor Stefanik 2009-02-04 09:03:29 PST
My proposal: Allow separate control over NPN_UserAgent and the User-Agent: HTTP header.

Like this:
-If neither general.useragent.override nor general.useragent.pluginoverride is set, use the real UA for both User-Agent: and NPN_UserAgent.
-If general.useragent.override is set, but general.useragent.pluginoverride is unset, both should return general.useragent.override
-If both are set, User-Agent: should return general.useragent.override, while NPN_UserAgent should return general.useragent.pluginoverride.
-If only general.useragent.pluginoverride is set, use the original UA for User-Agent:, and use general.useragent.pluginoverride for NPN_UserAgent.
Comment 184 Ben Bucksch (:BenB) 2009-02-04 09:17:45 PST
> Agreed that the UA must not leak.
> > There would need to be a new call for the plugin's internal needs to
> > differentiate browsers and adapt their own behaviour.
> Disagree here.

If we let the old API call return the real UA, older plugins opening their own streams will leak the UA. Therefore, UAs which depend on the real UA for internal needs need to be updated.
Comment 185 Mikko Rantalainen 2010-03-10 01:50:38 PST
(In reply to comment #184)
> If we let the old API call return the real UA, older plugins opening their own
> streams will leak the UA. Therefore, UAs which depend on the real UA for
> internal needs need to be updated.

Perhaps I'm totally off course here, but I think that if a plugin is opening their own streams without using NPAPI, they shouldn't be claiming to be the UA. I think that the UA in the HTTP header should be the piece of software that is making the request.

An example where this difference matters:
1) Plugin FOO has a broken keep-alive implementation
2) Plugin FOO uses UA's UA string for its own network streams
3) Server administrator must disable all keep-alive support for all network streams with UA string despite the fact that the only thing with incorrect implementation of keep-alive support is the broken plugin FOO.

An old plugin leaking the real UA string to the network is the broken one. Not some newer plugin that wants to know the real UA string.
Comment 186 timeless 2010-03-10 02:47:16 PST
Mikko: the fact is that the api was designed to enable, and for plugins to actually use the useragent while making requests. and plugins *do* this.

We can't simply change the api now.

We could add a new api, and we could probably add some other programmatic bits. FWIW I believe that a plugin can probably probe the navigator object to find the information it wants. Trying to parse a useragent string is a foolish task.

There are major and minor version numbers which should exist in the plugin api, and they should change from time to time, so i suspect that a plugin could figure out which browser it was dealing with by using those instead.

given that our browser changes from minor version to minor version, i'm not sure that relying on parsing the useragent would work too well anyway.
Comment 187 Gábor Stefanik 2010-10-16 18:23:47 PDT
Open bugs should not live in Core Graveyard.
Comment 188 patheticcockroach 2011-01-25 01:59:16 PST
Is this bug still occurring? I just tried (Minefield 2011-01-23 x64) changing my UA and then loading Java on http://www.java.com/en/download/installed.jsp and everything worked fine.
Comment 189 Todd 2011-01-25 10:48:25 PST
I can not remember it being a problem for a while now.
Comment 190 Geoff Norton 2011-01-25 10:59:44 PST
Before closing a 10 year old bug as WORKSFORME, could we please have some final decision on #c176 onwards, as there is pretty clearly (to me) still an issue here.
Comment 191 Ben Bucksch (:BenB) 2011-01-25 11:14:49 PST
> The Moonlight plugin needs to know wether we're running in FF2 or FF3

FF2 doesn't exist anymore. Does that solve this particular problem you had?

NPN_Version does not help?
For the NPAPI problem, you could file a new bug and cross-reference them.

This bug is about a Java crash. If nobody sees this anymore, this is fixed.
Comment 192 inaxabashi 2013-05-29 17:18:53 PDT
(In reply to Ben Bucksch (:BenB) from comment #191)
> > The Moonlight plugin needs to know wether we're running in FF2 or FF3
> 
> FF2 doesn't exist anymore. Does that solve this particular problem you had?
> 
> NPN_Version does not help?
> For the NPAPI problem, you could file a new bug and cross-reference them.
> 
> This bug is about a Java crash. If nobody sees this anymore, this is fixed.

(In reply to Geoff Norton from comment #190)
> Before closing a 10 year old bug as WORKSFORME, could we please have some
> final decision on #c176 onwards, as there is pretty clearly (to me) still an
> issue here.

(In reply to Todd from comment #189)
> I can not remember it being a problem for a while now.

Note You need to log in before you can comment on or make changes to this bug.