14 years ago
Component: Preferences → Security
QA Contact: preferences → firefox
No action? You can also use (obviously) JRE 5.0 Update 4, which was just released, to reproduce this.
I don't believe that it is the site bypassing the preference... rather it is the preference not being honored when the plugins are placed in either the app's plugins directory or the plugins directory above the profile directory (e.g. mozilla/plugins). I know the preference was honored in earlier builds so I suspect this is a regression. A regression window would be helpful here.
BTW: the preference was honored for me when the java plugins were NOT in app, etc. and it was honored when they were not located in either of those locations
Confirmed. It only occurs when the plugins are placed in the Firefox plugins directory. There was a time when I could not get Java applets to work in Firefox (I believe earlier than 0.8 ) until I copied the plugins over. Ever since then, that is what I automatically did with each install. Now I have verified that applets work without placing those plugins in the Firefox directory. Not sure how to proceed from here.
I can confirm this behavior as well. A few notes though: 1) This does not occur on the website http://www.java.com/en/ I haven't been seeking out a ton of test sites due to time constraints though. 2) It should be noted that no actual java code execution takes place. Then again, the test page in the bug doesn't actually execute any java code even when you have it properly enabled. Whether or not java code can actually be executed via this bug, instead of just opening the java console, remains to be thoroughly tested. HOWEVER, since even the console should not be opening with Java disabled... this is definitely a bug. It's the severity I'm unsure about.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Johnny, this looks bad. Can you look into it or recommend someone else?
Assignee: nobody → jst
Flags: blocking1.8b4+ → blocking1.8b4?
doron, is this something you could help us investigate? JST is pretty doomed right now. If not, any ideas who could help out?
http://lxr.mozilla.org/seamonkey/source/js/src/liveconnect/jsj_JavaPackage.c seems to be the code in question, and I defer to shaver. This is supposed to be standalone code and all, so someone who knows the engine needs to figure out how (if at all) we should do this.
What in that file, specifically, do you think is the code in question? All of LiveConnect's interaction with the JVM is mediated through the callbacks installed here: http://lxr.mozilla.org/seamonkey/source/modules/oji/src/lcglue.cpp#402 so if something is not honouring the pref correctly, it'll be elsewhere. When this is happening, what do we find for the status at http://lxr.mozilla.org/seamonkey/source/modules/oji/src/jvmmgr.cpp#73 ?
debugger shows status as nsJVMStatus_Enabled.
nsJVMManager::nsJVMManager adds an pref observer, but doesn't actually get the prev value and call SetJVMEnabled - http://lxr.mozilla.org/seamonkey/source/modules/oji/src/nsJVMManager.cpp#368 Adding that seems to fix the issue for me. Not sure if that is the right way to go.
Sounds good to me too -- I'll give you the bug as a prize for your detective work! Wanna put a patch up?
Assignee: jst → doronr
Component: Plug-ins → Java: OJI
Created attachment 193188 [details] [diff] [review] proposed patch
Attachment #193188 - Flags: superreview?(shaver)
Comment on attachment 193188 [details] [diff] [review] proposed patch If we can't get the pref, we default to...what? I guess "on", because that's what we get without that code. sr=shaver
Attachment #193188 - Flags: superreview?(shaver) → superreview+
(In reply to comment #15) > (From update of attachment 193188 [details] [diff] [review] ) > If we can't get the pref, we default to...what? I guess "on", because that's > what we get without that code. sr=shaver > I could call SetJVMEnabled(prefBool) if we couldn't get the prefservice or pref, since prefBool defaults to true.
Comment on attachment 193188 [details] [diff] [review] proposed patch r=jst
Attachment #193188 - Flags: review?(jst) → review+
bah. you're duplicating code. i'd prefer you poke Observe and pretend the pref has changed.
checked into trunk/1.8 branch
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.