Closed Bug 670655 Opened 14 years ago Closed 14 years ago

Accessing Java site freezes Firefox 3.6.19 on Mac OS X 10.7

Categories

(Plugins Graveyard :: Java (Java Embedding Plugin), defect)

Product:
Plugins Graveyard
Component:
Java (Java Embedding Plugin)
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: george.carstoiu, Assigned: smichaud)

Details

(Keywords: verified1.9.2)

Attachments

(1 file)

Simple, hacky workaround
2.89 KB, patch
BenWa
: review+
christian
: approval1.9.2.20+
Details | Diff | Splinter Review
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.19) Gecko/20110707 Firefox/3.6.19 Accessing a website like http://www.java.com/en/download/testjava.jsp freezes Firefox. Reproducible: always Steps to reproduce: 1. Open Firefox 2. Go to http://www.java.com/en/download/testjava.jsp Actual results: - the browser becomes unresponsive and has to be close with the kill command Expected results: - the browser loads the desired page Java Embedding Plugin 0.9.7.5 File: MRJPlugin.plugin Version: MRJ Plugin version 1.0-JEP-0.9.7.5 Runs Java applets using the latest installed versions of Java. For more information: Java Embedding Plugin. Run version test: Java Information. MIME Type Description Suffixes Enabled application/x-java-applet;version=1.2 Embedded Java Applet xja12 Yes application/x-java-applet;version=1.3.1 Embedded Java Applet xja131 Yes application/x-java-applet;version=1.1.2 Embedded Java Applet xja112 Yes application/x-java-applet;version=1.2.1 Embedded Java Applet xja121 Yes application/x-java-applet;version=1.5 Embedded Java Applet xja15 Yes application/x-java-applet;version=1.4.2 Embedded Java Applet xja142 Yes application/x-java-applet;version=1.3 Embedded Java Applet xja13 Yes application/x-java-applet;version=1.1.1 Embedded Java Applet xja111 Yes application/x-java-applet;version=1.1 Embedded Java Applet xja11 Yes application/x-java-applet Embedded Java Applet xja Yes application/x-java-vm Embedded JVM xjv Yes application/x-java-applet;version=1.1.3 Embedded Java Applet xja113 Yes application/x-java-applet;version=1.4.1 Embedded Java Applet xja141 Yes application/x-java-applet;version=1.6 Embedded Java Applet xja16 Yes application/x-java-applet;version=1.4 Embedded Java Applet xja14 Yes application/x-java-applet;version=1.2.2 Embedded Java Applet xja122 Yes
Dan and Christian, Waverly found this problem on 3.6.19 this morning. I'm not sure it isn't because of Java's deprecated state on 10.7. George, did different waverly testers see this on multiple machines or was this only tested on one machine?
On my 10.7 system, which is a migration from an OS X 10.6.8 system, the following happens. 1. Open Firefox 3.6.19 2. OS X closes 3.6.19 and says that I need to download Java for OS X 10.7 3. System downloads Java, installs it, and reopens Firefox 3.6.19 (automatically) 4. I load http://www.java.com/en/download/testjava.jsp 5. App loads page (partially). I have spinner on tab and can move the Firefox window around as a whole. All Firefox UI is unresponsive otherwise though. Firefox is frozen within itself even though I can move it around. Activity monitor does not report Firefox is non-responsive and it is only using 0.9% CPU (and it fluctuates as it sits there) and 81 MB of RAM. So this seems real and some kind of interaction with the OS X 10.7 Java changes.
I have to Force Quit, FYI, to get Firefox to shut down and become responsive.
We didn't change anything about Java for 3.6...I bet this is an existing issue. Can you reproduce with 3.6.18?
When I go to the same page in Firefox 5.0.1, the page loads and the plugin says "Inactive Plug-in" on the page. If I click on this, I get a system level dialog that says "To use this apple from 'www.java.com,' you will need to enable the Java plug-in. You need to restart your browser after enabling." with "cancel" and "enable" buttons. If I choose "enable" in 5.0.1, the dialog dismisses. If I choose "enable" and restart, the Java applet works in 5.0.1. If I open 3.6.19 after this, I still get the broken behavior though. If I disable JEP 0.9.7.5 in 3.6.19, the page will load. I note that there is ALSO a "Java Applet Plug-in 14.0.3" showing in the plugins under Firefox 3.6.19's add-ons tab.
Christian, the behavior is the same (bad) in 3.6.18. It hangs when I load the testjava.jsp page on 10.7.
Does it happen with a clean 10.7? Could it be a bug in Apple's migration scripts?
Couldn't tell you. We don't have clean 10.7 and OS X 10.7 installs are now failing during "downloading packages" in its install process so we couldn't make one. (I tried installing 10.7 multiple times on multiple computers during the last few days.)
On 10.5.8 users see only the JEP plugin. On 10.6.8 users see both the JEP and "Java Plug-in 2 for NPAPI browsers" 13.5.0 but java applets work. I thought the reason we have to fix java in 5.0.1 was because Apple moved the plugin in 10.7, and the reason we didn't have to fix 3.6.x was because we didn't use that plugin in that version. Yet there is it, found. Is "Java Plug-in 2 for NPAPI browser" the same as "Java Applet Plug-in"? the version difference 13.5 -> 14.0 suggests just an evolution of the same code.
If I disable "Java Applet Plug-in 14.0.3" and leave the JEP enabled, it still hangs the same way. This appears to be a JEP issue.
With 3.6.19 on 10.6 disabling the JEP disables Java. Doesn't matter whether the Java Plug-in 2 thing is enabled or disabled, we appear to ignore it.
I've noticed this too. It does appear to be a JEP issue -- in effect the 10.7 GM (Build 11A511) breaks the JEP. I'd have noticed this earlier, and tried to do something about it, except for the fact that earlier 10.7 DPs worked just fine with the JEP. To work around this, I'd normally tell people to remove the JEP from the FF 3.6.X distro's Contents/MacOS/plugins directory, and have FF use Java Plugin2 instead. But that won't help in this case, because 10.7 gives Java Plugin2 a new name, and FF 3.6.X can't find it under the new name. (FF 5.0 and up *do* know the new name as of the patch for bug 651618. But nobody thought we'd need this in older versions.)
The previous OS X 10.7 DP (build 11A494a) also breaks the JEP.
Assignee: nobody → smichaud
Component: General → Java (Java Embedding Plugin)
Product: Firefox → Plugins
QA Contact: general → jep-java
Version: 3.6 Branch → unspecified
Eh, I don't think we care about this...users needing Java in this situation can update to 5.
> Eh, I don't think we care about this...users needing Java in this > situation can update to 5. I agree. Bug 656990 is also unfixed in FF 3.6.X, which means that scrollbars get messed up where the arrows would normally have appeared (on earlier versions of OS X). And I don't know when I'll have the time to fix whatever Apple's latest 10.7 DPs have broken in the JEP.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
(Following up comment #12) > To work around this, I'd normally tell people to remove the JEP from > the FF 3.6.X distro's Contents/MacOS/plugins directory, and have FF > use Java Plugin2 instead. But that won't help in this case, because > 10.7 gives Java Plugin2 a new name, and FF 3.6.X can't find it under > the new name. This is wrong. FF 3.6.X has no trouble finding and running Java Plugin2 on OS X 10.7. The only thing it (like other versions of FF lacking the patch for bug 651618) does wrong is to run Java Plugin2 in process. So the workaround for this bug is to remove the JEP from your FF 3.6.X's distro, which involves removing JavaEmbeddingPlugin.bundle and MRJPlugin.plugin from your distro's Contents/MacOS/plugins/ directory.
Normal users aren't going to do that, they should just open the add-ons dialog and disable the JEP. I disagree with the "WONTFIX" on this bug. Might be the right choice for 3.6.19 (but it should be made by product/release managers, not developers) but there's no reason we can't fix this for the planned 3.6.20 release. (If Apple moved the plugin, why can 3.6.x find it when 5.0 could not?)
Status: RESOLVED → REOPENED
blocking1.9.2: --- → ?
status1.9.2: --- → wanted
Resolution: WONTFIX → ---
> (If Apple moved the plugin, why can 3.6.x find it when 5.0 could not?) You've mixed up two different (and unrelated) bugs. Apple's Java for Mac OS X 10.5 Update 10 removed the shortcut to Java Plugin2 from /Library/Internet Plug-Ins/. That's bug 668639. This bug is completely unrelated.
> there's no reason we can't fix this for the planned 3.6.20 release I'm afraid that there *is* a good reason: The only reasonable way to fix this bug is to change the JEP to work around whatever breakage Apple's most recent OS X 10.7 DPs have introduced. And I currently have zero time to work on the JEP (without taking time off from my Mozilla work). Though I suppose we could hack something to force FF 3.6.20 not to use the JEP on OS X 10.7 and up (and instead use Java Plugin2).
And by the way, I'm not suggesting that ordinary users use my workaround from comment #16. I agree with Christian -- we should tell ordinary users to use FF 5 and up on OS X 10.7.
(In reply to comment #16) > This is wrong. FF 3.6.X has no trouble finding and running Java > Plugin2 on OS X 10.7. Really? Apple added Carbon event model support to Plugin2 in 10.7?
(In reply to comment #21) Try it for yourself. I don't remember seeing any major problems. It probably helps that Java Plugin2 itself has two processes (one intended to run in the browser process and one not), and I think it's the non-browser-process that handles the display.
I should have said that Java Plugin2 has two executables, one intended to be run in the browser process (to be forked by it) and one not.
> (to be forked by it) To be loaded into it as a plugin. Sigh.
Wow, it works on 10.6 now too (I asked because I don't have 10.7 installed anywhere to test with). When I had last looked Plugin2 was Cocoa-only, thus my surprise that they actually went back and added legacy-model support.
> Though I suppose we could hack something to force FF 3.6.20 not to use > the JEP on OS X 10.7 and up (and instead use Java Plugin2). I'll be working on a patch that does this. I should be able to post it today or tomorrow.
Here's the patch I promised in comment #26. It fails over from the JEP to Java Plugin2 on OS X 10.7 (Lion). On other versions of OS X, the behavior is the same as before (Java applets are loaded using the bundled JEP). Here's a test build. It's not a tryserver build (since we've never managed to get those working again on the branches) -- instead it's one I made myself. Please try it out! http://people.mozilla.com/~stmichaud/bmo/firefox-3.6.20pre.en-US.mac.bugzilla670655.dmg I've kept it as simple as possible, to make it as low-risk as possible. You'll notice that I don't allow *any* version of the JEP to be loaded on OS X 10.7 (and up). I'm unlikely in the forseeable future to have time to get the JEP working on 10.7 (in the past, each new major version of OS X has required weeks of work on the JEP). But it's possible that I may need to release a new JEP version to deal with some unanticipated bug (or security hole) -- and if so, I don't want to have to spend extra time getting the (hypothetical) new version working on OS X 10.7. Some will also notice that I've added yet another copy of our OS X version detection code to the tree. Ideally there should only be one copy, callable from anywhere in the tree -- possibly in Cocoa widgets' nsToolkit class (or something like it). But that's work for another time.
Attachment #545393 - Flags: review?(bgirard)
Attachment #545393 - Attachment description: Simle, hacky workaround → Simple, hacky workaround
blocking1.9.2: ? → .20+
(In reply to comment #27) > Here's a test build. It's not a tryserver build (since we've never > managed to get those working again on the branches) -- instead it's > one I made myself. Please try it out! > > http://people.mozilla.com/~stmichaud/bmo/firefox-3.6.20pre.en-US.mac. > bugzilla670655.dmg I tested this and the browser no longer hangs. Instead, the page loads and it tells me, on the page and in a gold bar, that I need to install additional plugins for this page. When I select that, the plugin finder dialog opens but then says it cannot find the needed plugin. I'm not sure if that was the intent but it doesn't hang at least.
Al, I assume you're testing on a copy of OS X 10.7 where Java has never been installed. What happens when you try to load a Java applet in Safari on the same system?
This was the same 10.7 I was using yesterday where 5.0.1 got a system level prompt to install Java and I did so. I used http://java.sun.com/applets/jdk/1.4/demo/applets/Clock/example1.html too.
I just downloaded my test build again and tested it with a fresh profile, using the same Clock applet -- it ran just fine. I tested on the 10.7 GM, where I've had Java installed for a couple of weeks. I'll try installing another copy of the 10.7 GM (without Java), and see what happens with it.
Al, please test again with a fresh profile.
And please ensure that Java is working correctly in FF 5 and Safari, on the machine you're testing on.
Ok, if I use a new profile with your build on http://java.sun.com/applets/jdk/1.4/demo/applets/Clock/example1.html, I get the clock applet fine. The same goes for Safari or Firefox 5.0.1. This does beg the question of what happens to users with certain kinds of dirty profiles.
> This does beg the question of what happens to users with certain > kinds of dirty profiles. Dirty profiles cause all kinds of problems, and those bugs are among the hardest to resolve. I don't think we should let that stop us here. I'm still waiting for my 2nd copy of the 10.7 GM to finish installing.
OK, I've now tested with my test build (from comment #27) with my new (Javaless) installation of the 10.7 GM (build 11A511), and everything went fine. The first time I visited http://java.sun.com/applets/jdk/1.4/demo/applets/Clock/example1.html I got the Missing Plug-In icon. I clicked on it and followed the prompts to download and install Java. Then I quit the browser, restarted it, and visited http://java.sun.com/applets/jdk/1.4/demo/applets/Clock/example1.html again. This time the Clock applet loaded with no problems (using the newly downloaded Java Plugin2).
Attachment #545393 - Flags: review?(bgirard) → review+
Comment on attachment 545393 [details] [diff] [review] Simple, hacky workaround This is a very simple, low-risk patch that only effects behavior on OS X 10.7 (and up): It prevents the JEP from being loaded on 10.7 and up, which causes FF 3.6.X to fail over to Java Plugin2. This is the scalpel we should be using instead of bug 670767's meat axe :-)
Attachment #545393 - Flags: approval1.9.2.20?
Comment on attachment 545393 [details] [diff] [review] Simple, hacky workaround a=LegNeato for releases/mozilla-1.9.2
Attachment #545393 - Flags: approval1.9.2.20? → approval1.9.2.20+
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
status1.9.2: wanted → .20-fixed
Resolution: --- → FIXED
Still fixed in 1.9.2.20: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.20pre) Gecko/20110726 Namoroka/3.6.20pre
Keywords: verified1.9.2
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.2.20) Gecko/20110803 Firefox/3.6.20 Verified issue on FF 3.6.20 on Mac OS X 10.7 using the STR from the description. Setting resolution to VERIFIED FIXED.
Status: RESOLVED → VERIFIED
Accessing http://www.java.com/en/download/testjava.jsp using Firefox 3.6.24 (1.9.2 branch) on OSX 10.7.2 applet will now not display. So it appears that the update of OSX to 10.7.2 has regressed this fix.
> So it appears that the update of OSX to 10.7.2 has regressed this > fix. No. It's a new problem -- one I suspect was caused by Apple's most recent Java update for OS X 10.7, "Java for OS X Lion Update 1" (http://support.apple.com/kb/DL1421). The problem is that Java applets simply fail to load in FF 3.6.2X on OS X 10.7.2, with Java for OS X Lion Update 1 installed. There's no freeze. It makes no difference whether or not the JEP is bundled. Interestingly, you get the same thing if you remove the bundled JEP from FF 3.6.19 or 3.5.19 -- no freeze, but Java applets fail to load. Changing FF 3.6.24's useragent string to match FF 8's makes no difference. But I suspect Apple's latest Java Update is somehow detecting FF 3.6.X and below and refusing to load Java applets on those versions. I'll open a new bug on this as soon as I get the chance, and report the problem to Apple. But I doubt we'll try to work around the problem on our end -- FF 3.6.X is simply too old.
I just confirmed that the new problem (described in comment #43) doesn't exist on OS X 10.7.2 if Java for OS X Lion Update 1 isn't installed.
(In reply to Steven Michaud from comment #43) > I'll open a new bug on this as soon as I get the chance, and report > the problem to Apple. But I doubt we'll try to work around the No need; see bug 701968 and rdar://10436669 . It sounds like Apple might have dropped Carbon event support from the latest Java update.
> It sounds like Apple might have dropped Carbon event support from the latest Java update. This didn't turn out to be the case, so the new issue might be work-around-able. Someone need to figure out what exactly it is though.
(In reply to Steven Michaud from comment #43) > But I suspect Apple's latest Java Update is somehow > detecting FF 3.6.X and below and refusing to load Java applets on > those versions. Yes, since 3.6.x is the last mozilla universal build release to support ppc and i386 w/ no 64 bit (x86_64) support, and 4.x and up supports x86_64, I think this is the detection that is being made as you suggest. It probably just doesn't support 32 bit (i386) binaries at this point ... So because 3.6.x has no 64 bit support, I don't think a work around can be implemented.
(In reply to Pete Collins (MDG) from comment #47) > (In reply to Steven Michaud from comment #43) > > > But I suspect Apple's latest Java Update is somehow > > detecting FF 3.6.X and below and refusing to load Java applets on > > those versions. It turns out this probably isn't true. > Yes, since 3.6.x is the last mozilla universal build release to support ppc > and i386 w/ no 64 bit (x86_64) support, and 4.x and up supports x86_64, I > think this is the detection that is being made as you suggest. > > It probably just doesn't support 32 bit (i386) binaries at this point ... Nor is this. See bug 701968 comment 14, et seq, for a theoretical workaround.
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: