Remove the JEP from Camino 2.1

RESOLVED FIXED in Camino2.1

Status

--
major
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: alqahira, Assigned: alqahira)

Tracking

1.9.2 Branch
Camino2.1
All
Mac OS X
Bug Flags:
camino2.1 +
camino2.1b1 +

Details

Attachments

(1 attachment)

Due to bug 670655, Java is unusable (hangs the app) in Gecko 1.9.2 on 10.7.

We've already disabled Java for everyone moving to Cm2.1, but we might want to prevent users from enabling it (and perhaps re-disabling it at runtime on 10.7 for anyone who was on 10.5/10.6, flipped the pref back on, and then upgraded to 10.7).

Given the timeframes for 10.7 and 2.1/b1, I'm not sure if we want to try to slip this into b1 if we want to do this, but if we do want to do it, we should certainly make 2.1 final.

:sigh:
Flags: camino2.1b1?
Flags: camino2.1?
See also bug 670767.  Par for the course, between the two bugs, it sounds like no-one who understands things really knows what's going on. :P

Comment 2

7 years ago
So to my amazement, it appears that Plugin2 actually works in Gecko 1.9.2 now. That means we could do the disable-JEP-on-10.7 thing discussed in 670767 (I know we can do it in our implementation)
(In reply to comment #2)
> So to my amazement, it appears that Plugin2 actually works in Gecko 1.9.2
> now. That means we could do the disable-JEP-on-10.7 thing discussed in
> 670767 (I know we can do it in our implementation)

Yeah, let's do that (presuming the Plugin2-Gecko 1.9.2 combo continues working in the 10.7 release, but AIUI the build everyone is playing with now is the GM); Plugin2, with whatever foibles it may have, is surely better for our 10.7 users that need Java than preventing them from using Java entirely.

(I also presume JEP in 2.0.x will behave similarly badly on 10.7, so hopefully we can get b1 out shortly.)
Summary: Consider preventing users from enabling Java on 10.7 → Blocklist the JEP on 10.7

Comment 4

7 years ago
Well, this is awesome. If I disable the JEP, then Java doesn't work. If I actually rip the JEP out of the bundle, it does. (My guess is that the plugin system is answering the question "is there a plugin for this MIME type" by finding the first plugin matching the MIME type and then checking to see if it's enabled and unblocked; that's pure speculation though).

I guess we watch the other bug and see what happens. Or we mini-branch core plugin code and I hack up an exclusion deep in there.

Comment 5

7 years ago
So here's a thought, which I like more and more the more I think about it: We pull JEP from 2.1.

10.6 and 10.7 users (maybe even 10.5? not sure the status there) would get Plugin2. 10.4 (and 10.5?) users could install JEP themselves if they wanted to, just like they would any other plugin.

Yes, it might inconvenience some people, but it's not like we are particularly pro-Java-plugin around here. And not shipping it means we are no longer a potential bottleneck for Java security updates, since if Apple updates Plugin2 we get that for free.
(In reply to comment #4)
> Well, this is awesome. If I disable the JEP, then Java doesn't work. If I
> actually rip the JEP out of the bundle, it does. (My guess is that the
> plugin system is answering the question "is there a plugin for this MIME
> type" by finding the first plugin matching the MIME type and then checking
> to see if it's enabled and unblocked; that's pure speculation though).

And checks the in-bundle location (Gecko's plugins/ folder) before any other locations.  IIRC this code changed between 1.9.0 and 1.9.2, because Steven had to change his "how to test" instructions to start directing people to remove the in-bundle copy.

(In reply to comment #5)
> So here's a thought, which I like more and more the more I think about it:
> We pull JEP from 2.1.

> 10.6 and 10.7 users (maybe even 10.5? not sure the status there) would get
> Plugin2.

Steven is of the opinion that, on OS versions where it works, JEP still does things better than Plugin2.  FWIW ;-)  But, as you've stated, anyone can install it themselves, so people on 10.6 can choose whichever works best for their needs.

Bug 668639 is the status on 10.5; if you've installed the latest Apple Java update, Plugin2 is now hidden where Gecko won't find it, so Camino thinks Java isn't installed.  (FWIW, if I restore the Plugin2 symlink, it seems like the applet is run out-of-process!? Applets spawn a separate application which owns those windows.)

> 10.4 (and 10.5?) users could install JEP themselves if they wanted
> to, just like they would any other plugin.

Given that we have the profile plug-ins folder in 2.1, that's now possible without confusing/breaking other browsers.

> Yes, it might inconvenience some people, but it's not like we are
> particularly pro-Java-plugin around here. And not shipping it means we are
> no longer a potential bottleneck for Java security updates, since if Apple
> updates Plugin2 we get that for free.

Well, we'd have to host the JEP download ourselves, so we're not entirely off the hook (Steven has never publicly released the last JEP versions--they've just been landed in the tree--and we have some users who refuse to upgrade Camino 2.0.x because we're shipping a JEP that's not available from javaplugin.sf.net :P )

Let me sleep on it, but I think I'm inclined to agree with you on the choice of solution.  "Code"-wise, it's dead simple.  We'd have to make some website changes and figure out how to "build" and "release" the latest JEP for download, but those seem more solvable than the forking mozilla/plugin/.

Comment 7

7 years ago
(In reply to comment #6)

> Well, we'd have to host the JEP download ourselves, so we're not entirely
> off the hook (Steven has never publicly released the last JEP
> versions--they've just been landed in the tree--and we have some users who
> refuse to upgrade Camino 2.0.x because we're shipping a JEP that's not
> available from javaplugin.sf.net :P )

FWIW, JEP 0.9.7.5 (same as what ships in a Camino nightly) is available:
http://sourceforge.net/projects/javaplugin/files/javaplugin/

I like the idea of removing JEP completely, btw.

Comment 8

7 years ago
Looks like there's going to be a hack-around in bug 670655, but I still prefer the idea of just not shipping it and letting people who want it install it.
(In reply to comment #7)
> FWIW, JEP 0.9.7.5 (same as what ships in a Camino nightly) is available:
> http://sourceforge.net/projects/javaplugin/files/javaplugin/

Oh, good.  I'd somehow never seen the comments where he went ahead and released it.

His readme/installation instructions and .zip file structure are somewhat sub-optimal for our purposes, but still better than maintaining our own download.  Worst-case, we can link our Setup page's plug-ins entry to a wiki page with better instructions, and I can repurpose the old "Fix JEP for 1.6 on 10.6" AppleScript app to do the same for the JEP.

(In reply to comment #8)
> Looks like there's going to be a hack-around in bug 670655, but I still
> prefer the idea of just not shipping it and letting people who want it
> install it.

Assuming the hack-around ever lands, it'll just be extra protection for people on 10.7, which will be nice.

Given the fact he's now pledged to release the source/binaries before landing them in the tree, though, I now don't see any reason not to stop shipping it. (Is that enough negatives?)
Assignee: nobody → alqahira
Status: NEW → ASSIGNED
Flags: camino2.1? → camino2.1+
Summary: Blocklist the JEP on 10.7 → Remove the JEP from Camino 2.1
Target Milestone: --- → Camino2.1

Comment 10

7 years ago
(In reply to comment #9)
> (Is that enough negatives?)

I would certainly never say that it's not.

I'll make the project changes tonight or tomorrow morning.
Created attachment 545443 [details] [diff] [review]
JEP-ectomy

One drawback of this approach, I just realized, is that we'll no longer get JEP frames in crashes resymbolized for those users, e.g., in crashes like bp-79633ed3-747f-4751-9270-b65bf2110502 (unless maybe the module ID remains unchanged and Socorro is smart enough to pull a matching module ID from an old version of Camino; dunno.  The module IDs do appear to remain unchanged across 2.0.6 and 2.0.7).

Also, Camino.app/Contents/MacOS/plugins (the Gecko plug-ins dir) no longer gets created, but since we have our own profile plug-ins folder we want people to use now, I don't think that matters; no-one should be hacking the bundle anymore to install plug-ins, components, or chrome.
Attachment #545443 - Flags: superreview?(stuart.morgan+bugzilla)
(In reply to comment #10)
> I'll make the project changes tonight or tomorrow morning.

Oops, I beat you to that--and, wow, for the first time ever, I didn't get a conflict warning when attaching a patch to a bug that had comments added after I opened the patch upload page.
I'd like to get bug 671037 fixed before landing this, too, so that anyone who updates to the nightly and needs Java will have a recourse to documentation.

Comment 14

7 years ago
Comment on attachment 545443 [details] [diff] [review]
JEP-ectomy

sr=smorgan, thanks for taking care of it.
Attachment #545443 - Flags: superreview?(stuart.morgan+bugzilla) → superreview+

Comment 15

7 years ago
(In reply to comment #11)
> One drawback of this approach, I just realized, is that we'll no longer get
> JEP frames in crashes resymbolized for those users

Yeah, I don't really care. The symbols aren't all that useful to us, and if he wants symbols he can keep them for his builds (heck, he could probably even get them uploaded to the crash server if he didn't want to do his own symbolication)

> I don't think that matters; no-one should be hacking the
> bundle anymore to install plug-ins, components, or chrome.

Agreed.
http://hg.mozilla.org/camino/rev/b913f41888dc

You'll need to distclean your trees (or similar) to remove it from your development Caminos, but it'll be gone from tonight's nightly.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Flags: camino2.1b1? → camino2.1b1+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.