Closed Bug 83376 Opened 24 years ago Closed 14 years ago

Crash loading Java Plugin if UserAgent string is changed ("Java Plug-in for Netscape Navigator should not be used in Microsoft Internet Explorer")

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: Erich.Iseli, Unassigned)

References

Details

(Keywords: crash, Whiteboard: redesign)

Attachments

(7 files, 5 obsolete files)

Java Plug-In error message
16.01 KB, image/png
Details
example showing how to change UA with Javascript through HTML
599 bytes, text/plain
Details
a new method to get "system" useragent
4.72 KB, patch
Details | Diff | Splinter Review
Message window when opening FireFox, while defalt set to IE.
28.09 KB, image/jpeg
Details
Manual removal instructions for those not following the comment trail
954 bytes, text/plain
Details
improved User Agent Switcher extension as a workaround (or a bugfix?)
32.32 KB, application/x-xpinstall
Details
An early (not final) version of the fixed extension was attached earlier. Here is the right one :-)
32.65 KB, application/x-xpinstall
Details
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.
component: OJI
Assignee: av → edburns
Component: Plug-ins → OJI
Not Blocker, just Critical...
Severity: blocker → critical
Keywords: crash
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.
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.
I have confirmed this happens on win32. I have filed Sun internal bugtraq bug 4465932. Re-assigning to Jim.
Assignee: edburns → James.Melvin
Keywords: nsenterprise
Marking INVALID [jpibug]
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Whiteboard: [jpibug]
What is jpibug meaning? Could anyone provide a link to the bug report at sun? thanks.
*** Bug 89132 has been marked as a duplicate of this bug. ***
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
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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.
This bug certainly blocks RFE bug 46029. Unless we stop using Sun Java :-( Marking the block.
Blocks: 46029
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 ?
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.
This is in Java Plugin Group's realm. Removing me from CC.
*** Bug 92775 has been marked as a duplicate of this bug. ***
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.
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...
SPAM: reassigning all OJI bugs to new OJI QA, pmac ( 227 bugs)
QA Contact: shrir → pmac
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.
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.
*** Bug 95786 has been marked as a duplicate of this bug. ***
OS: Windows 98 → All
*** Bug 95786 has been marked as a duplicate of this bug. ***
Removing nsenterprise nomination.
Keywords: nsenterprise
*** Bug 97596 has been marked as a duplicate of this bug. ***
Blocks: 98995
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.
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!
> 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.
Blocks: 101990
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?
No longer blocks: 101990
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.
*** Bug 105259 has been marked as a duplicate of this bug. ***
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."
Attached patch Possible fix, #1 (obsolete) — — Splinter Review
Attached patch Possible fix, part 2 (obsolete) — — Splinter Review
Attached patch Possible fix, part 3 (obsolete) — — Splinter Review
Attached patch Possible fix, part 4 (obsolete) — — Splinter Review
I'd prefer the alternative. lemme spend my morning on it.
Assignee: James.Melvin → zav
Status: REOPENED → NEW
*** Bug 106727 has been marked as a duplicate of this bug. ***
*** Bug 111281 has been marked as a duplicate of this bug. ***
*** Bug 117705 has been marked as a duplicate of this bug. ***
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.
try -nosplash/-quiet
timeless: what about alternative solution for this bug? Or may be we can go with Alexander's one?
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.
Alexander Zuev is no longer working on OJI. -> Joe
Assignee: zav → joe.chou
Will be fixed on mozilla side -> removing obsolete keyword
Blocks: 101353
Whiteboard: [jpibug]
This one is important. Let's try to fix it by 1.0
Target Milestone: --- → mozilla1.0
*** Bug 134779 has been marked as a duplicate of this bug. ***
*** Bug 140215 has been marked as a duplicate of this bug. ***
*** Bug 140791 has been marked as a duplicate of this bug. ***
This bug seemed to have been fixed for .99 but it's broken again as of 1.0 RC1
*** Bug 146093 has been marked as a duplicate of this bug. ***
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?)
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.]
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 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 :)
Attachment #86806 - Attachment mime type: text/html → text/plain
*** Bug 167359 has been marked as a duplicate of this bug. ***
Blocks: 106727
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.
*** Bug 106727 has been marked as a duplicate of this bug. ***
*** Bug 167593 has been marked as a duplicate of this bug. ***
*** Bug 173248 has been marked as a duplicate of this bug. ***
Chris Petersen is a new QA contact for oji component. His email is: petersen@netscape.com
Assignee: joe.chou → petersen
reassign to joe chou
Assignee: petersen → joe.chou
QA Contact: pmac → petersen
*** Bug 175247 has been marked as a duplicate of this bug. ***
*** Bug 183900 has been marked as a duplicate of this bug. ***
*** Bug 186240 has been marked as a duplicate of this bug. ***
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
Target Milestone: mozilla1.0 → ---
*** Bug 186913 has been marked as a duplicate of this bug. ***
*** Bug 170025 has been marked as a duplicate of this bug. ***
--->default owner
Assignee: joe.chou → joshua.xia
QA Contact: petersen → dsirnapalli
*** Bug 196842 has been marked as a duplicate of this bug. ***
*** Bug 202134 has been marked as a duplicate of this bug. ***
*** Bug 200968 has been marked as a duplicate of this bug. ***
is this still happening with more recent software versions? (bug cleaning)
It doesn't crash, but still gives the error about the plugin being wrong.
Status: NEW → ASSIGNED
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?
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?
*** Bug 213106 has been marked as a duplicate of this bug. ***
*** Bug 164823 has been marked as a duplicate of this bug. ***
Whiteboard: redesign
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)
->kyle
Assignee: joshua.xia → kyle.yuan
Status: ASSIGNED → NEW
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?
Kyle, Can you verify whether this bug is still valid in JRE 1.5?
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.
this means some duplicate work but can avoid api change.
Attachment #140482 - Flags: review?(Xiaobin.Lu)
*** Bug 187402 has been marked as a duplicate of this bug. ***
Attachment #140482 - Flags: review?(Xiaobin.Lu) → review+
Attachment #140482 - Flags: superreview?(darin)
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?
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.
Status: NEW → ASSIGNED
It's better than re-create the wheel if we can change the nsIHttpProtocolHandler api.
Attachment #55053 - Attachment is obsolete: true
Attachment #55054 - Attachment is obsolete: true
Attachment #55055 - Attachment is obsolete: true
Attachment #55057 - Attachment is obsolete: true
Attachment #140482 - Attachment is obsolete: true
Comment on attachment 140589 [details] [diff] [review] a new method to get "system" useragent darin, how about this one?
Attachment #140589 - Flags: superreview?(darin)
Attachment #140589 - Flags: review?(Xiaobin.Lu)
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?
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 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.
Attachment #140589 - Flags: superreview?(darin)
Attachment #140589 - Flags: review?(Xiaobin.Lu)
Attachment #140482 - Flags: superreview?(darin)
*** Bug 233581 has been marked as a duplicate of this bug. ***
*** Bug 234041 has been marked as a duplicate of this bug. ***
*** Bug 236430 has been marked as a duplicate of this bug. ***
*** Bug 238244 has been marked as a duplicate of this bug. ***
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?
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.
*** Bug 242306 has been marked as a duplicate of this bug. ***
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
*** Bug 258559 has been marked as a duplicate of this bug. ***
FireFox never opens, but maintains 99% CPU usage. FireFox Nightly build 1.0.
(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)
*** Bug 261592 has been marked as a duplicate of this bug. ***
*** Bug 261706 has been marked as a duplicate of this bug. ***
*** Bug 261317 has been marked as a duplicate of this bug. ***
*** Bug 269948 has been marked as a duplicate of this bug. ***
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.
*** Bug 269289 has been marked as a duplicate of this bug. ***
*** Bug 270652 has been marked as a duplicate of this bug. ***
*** Bug 249594 has been marked as a duplicate of this bug. ***
*** Bug 270939 has been marked as a duplicate of this bug. ***
*** Bug 271006 has been marked as a duplicate of this bug. ***
*** Bug 272049 has been marked as a duplicate of this bug. ***
*** Bug 172724 has been marked as a duplicate of this bug. ***
*** Bug 272047 has been marked as a duplicate of this bug. ***
*** Bug 171550 has been marked as a duplicate of this bug. ***
*** Bug 196311 has been marked as a duplicate of this bug. ***
*** Bug 175500 has been marked as a duplicate of this bug. ***
Ugh. Very sorry about all the spam.
Summary: Crash when loading Java Plugin if UserAgent string as MSIE → Crash loading Java Plugin if UserAgent string is changed ("Java Plug-in for Netscape Navigator should not be used in Microsoft Internet Explorer")
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?
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.
Step by step instructions to remove the user agent switcher extension and change the user agent string back to normal
(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.
(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)
(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.
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?
(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
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).
(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.
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.
(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.
*** Bug 272539 has been marked as a duplicate of this bug. ***
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
(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.
*** Bug 275501 has been marked as a duplicate of this bug. ***
*** Bug 278734 has been marked as a duplicate of this bug. ***
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)
*** Bug 284681 has been marked as a duplicate of this bug. ***
*** Bug 285753 has been marked as a duplicate of this bug. ***
Comment #141, safe mode is for disabling extensions, not plugins, which is what Java is.
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
Filed bug 6212945 in Sun bug database to track this issue.
Blocks: majorbugs
No longer blocks: majorbugs
mass reassign my bugs to Pete Zha.
Assignee: kyle.yuan → pete.zha
Status: ASSIGNED → NEW
has anyone been able to fix this bug? Please Help!!
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).
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
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.
start > run > firefox -p ^^ make a new profile and it will be fixed but you will lose your stuff.
*** Bug 312757 has been marked as a duplicate of this bug. ***
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 ...
mass reassign to Alfred
Assignee: zhayupeng → alfred.peng
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
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
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.".
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.
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 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.
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().
> 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.
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.
Assignee: alfred.peng → jst
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!!!)
Can you shortly say how you implemented this (the trick used, not necessarily the code) instead of attaching a XPI?
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
(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 :-)
Well, an early version got uploaded. Sorry about that ;-) Please, use the attached version (especially Windows users!!!)
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.
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.
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
since it really does not look like a plugin-problem, why not change NPN_UserAgent() to always return the original user-agent? lg Clemens
QA Contact: dsirnapalli → java.oji
> 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 :-)
Is this still an issue?
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.
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".
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?
(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)
> 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.
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.
(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.
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.
> 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.
(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.
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.
Product: Core → Core Graveyard
Open bugs should not live in Core Graveyard.
Assignee: jst → nobody
Component: Java: OJI → Plug-ins
Product: Core Graveyard → Core
QA Contact: java.oji → plugins
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.
I can not remember it being a problem for a while now.
Status: NEW → RESOLVED
Closed: 23 years ago → 14 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
> 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.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → WORKSFORME
(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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: