Add "InstallerLocation" for Java in PFS -- Windows only

RESOLVED FIXED

Status

Websites
plugins.mozilla.org
RESOLVED FIXED
10 years ago
7 years ago

People

(Reporter: Benjamin Smedberg, Assigned: morgamic)

Tracking

Details

(Whiteboard: [server side][pfs])

Attachments

(7 attachments)

(Reporter)

Description

10 years ago
In order to get Java working in Firefox 3, we want to add an InstallerLocation to PFS for Java. This is apparently windows-only, at least by my testing:

Java InstallerLocation should be http://java.com/firefoxjre_exe

Mike, I think we'd like to do hashes as well, but I don't know how you work that out with Sun.

Comment 1

10 years ago
JRE installer on java.com is already digitally signed by Sun with certificate from Verisign.
So I don't think we need any other hash level for JRE binary, do we?

Comment 2

10 years ago
Mike, any update on this?

Also, currently, both FF2 and FF3's PFS client directly goes to Manual install for JRE.
Once the Auto Install URL (one that replaces <pfs:XPILocation>) has been set up correctly to point to the new native installer vanity link (http://java.com/firefoxjre_exe), could you please ensure that PFS' auto finding and install also work on Vista.

Thanks.
(Assignee)

Comment 3

10 years ago
Danielle - the .exe is for which versions of Windows?

Comment 4

10 years ago
What provided to you is a vanity link pointing to exe for all versions of Windows.
(Assignee)

Comment 5

10 years ago
Created attachment 308582 [details]
vista rendered RDF

Here is the resulting RDF for vista.
(Assignee)

Comment 6

10 years ago
Created attachment 308583 [details]
RDF for other versions of Windows
(Assignee)

Comment 7

10 years ago
Danielle - attached are the XML documents from a patched version of PFS.  You can hardcode pfs.datasource.url to point to these documents to test behavior.  Could you help test to verify that this works as expected on both Vista and XP?

Comment 8

10 years ago
Mike:
After hosting the pfs-nonvista.xml and adding
user_pref "pfs.datasource.url" to point to it (i.e, user_pref("pfs.datasource.url", "http://javaweb.sfbay/~dp144265/miscs/pfs-nonvista.xml");) in prefs.js, on XP, when PFS kicked in for Java, it goes to do "Minefield is now checking for available plugins" indefinitely without ever finished.

Did I setup pfs.datasource.url correctly?
Please advise.

I have not a chance to test Vista yet. Will do soon.
(Assignee)

Comment 9

10 years ago
Danielle, don't have to edit prefs.js, about:config works too.  Can you load that URL successfully in your browser?  Sounds like it's timing out trying to hit that url...

Comment 10

10 years ago
I'll test this against staging. 

morgamic: pfs.datasource.url = http://morgamic.khan.mozilla.org/amo-reskin/site/services/pfs.php?mimetype=%PLUGIN_MIMETYPE%&appID=%APP_ID%&appVersion=%APP_VERSION%&clientOS=%CLIENT_OS%&chromeLocale=%CHROME_LOCALE%
[3:04pm] morgamic: you can change it in about:config
[3:05pm] tchung: morgamic: easy enough.  that's the only config value i need to set?
[3:05pm] morgamic: yea
(Assignee)

Comment 11

10 years ago
Benjamin - this doesn't work for me and it gets stuck on a download error in the PFS UI.

We need some direction in where to debug this?  I'll attach some screenshots.
(Assignee)

Comment 12

10 years ago
Created attachment 314474 [details]
step 1, nothing unusual
(Assignee)

Comment 13

10 years ago
Created attachment 314475 [details]
step 2, got the install window as expected
(Assignee)

Comment 14

10 years ago
Created attachment 314476 [details]
step 3, after clicking 'next' there is a download error

The RDF in attachment 308582 [details] is according to spec and the hash matches so I am not sure what step to take next to fix this.
(Assignee)

Updated

10 years ago
Attachment #314476 - Attachment description: v3, after clicking 'next' there is a download error → step 3, after clicking 'next' there is a download error

Comment 15

10 years ago
Another screenshot and confirmation from my vista machine.   

http://img211.imageshack.us/img211/9055/pfssniffko3.jpg
(Assignee)

Comment 16

10 years ago
Hey so apparently it's something wrong with the url provided -- the # of redirects causes it to fail I think.  If I move the file to my local server (direct url) it "works".

Found another issue -- for the given RDF, it starts the .exe but then I get the PFS window saying that I have to use a manual install URL.  Is that expected?
(Assignee)

Comment 17

10 years ago
Created attachment 314482 [details]
step 4, direct .exe link works, but we get a quasi-state in Fx

Here we see that when I use a direct http link to the .exe (without redirects) we can install it, but while the external installer runs the dialog box for PFS goes to the manual download state, which is very confusing.  After the installer finishes, there is no indication that the user needs to restart.  What should be changed/added to the RDF to fix this?  Benjamin?
(Assignee)

Comment 18

10 years ago
Comment on attachment 314476 [details]
step 3, after clicking 'next' there is a download error

Note -- Step 3 is caused apparently by redirects -- is there a requirements that the external installer be served from a URL that doesn't have redirects?
(Reporter)

Comment 19

10 years ago
As for redirects, I thought they would work, but didn't do much verifying: the impl uses nsIDownloader directly. biesi, is there an issue with nsIDownloader and redirects?

Mike, is there anything interesting in the Error Console? I believe that the dialog should say "Install Successful".
(Assignee)

Comment 20

10 years ago
(In reply to comment #19)
> Mike, is there anything interesting in the Error Console? I believe that the
> dialog should say "Install Successful".
Agree -- that's why I screenshot it.  Doesn't seem to be any acknowledgement between execution of xpiinstall.exe and PFS.  My initial glance told me to check InstallerShowsUI, but that's true -- and so is needsRestart -- so I'm kind of at a loss to how I am supposed to debug this.  Is there a way to turn up debugging on vista?
nsIDownloader should transparently follow redirects. is that not what you're seeing?
(Assignee)

Comment 22

10 years ago
When I have this as the installerLocation it fails to download every time:
http://java.com/firefoxjre_exe
(Assignee)

Updated

10 years ago
Target Milestone: --- → 3.4

Comment 23

10 years ago
It seems to be working now, as i assume morgamic made changes to the rdf?  Anyway, i can see PFS now redirects to the .exe, and java proceeds to install directly.

Verified on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008040907 Minefield/3.0pre, against VPN into khan.mozilla.org

The only issue is, i can confirm attachment 4 [details] [diff] [review] also.   The PFS ui should be closed after the installer appears, no?   Instead, it reverts to a "Finished" UI, and that could be deceiving since its not really "Finished" until the user installs the plugin.    We can make this a separate bug unless already filed.
(Reporter)

Comment 24

10 years ago
For the UI: we don't have a good way to see if the native installer we launched has finished. Instead, after we launch the installer we immediately forward to the final wizard page. But, I believe it should say that installation completed successfully, not "no plugins were installed". I'll have to re-read the source and the original bug to confirm that was the intent and the code.

Comment 25

10 years ago
Yeah, that dialog is completely wrong.   Not only are "no plugins were installed.", but we should not prompt the user saying its not available and have a "manual install" button showing.

Comment 26

10 years ago
Mike and Ben,
Sorry but I'm still unable to test this work.
I hosted the 2 XMLs at http://www.freewebs.com/uchikake/work/pfs-nonvista.xml and http://www.freewebs.com/uchikake/work/pfs-vista.xml, then add user-defined pref pfs.datasource.url (via about:config) to point to it on XP and Vista, respectively. But testing still shows that when PFS kicks in for Java, it goes to do "Minefield is now checking for available plugins" indefinitely and never comes back.

Is there a mozilla hosted xml that I should point to now?
I use today nightly build of FF3.0pre.
If I don't change pfs.datasource.url, the default XML from Mozilla (https://pfs.mozilla.org/plugins/PluginFinderService.php?mimetype=%PLUGIN_MIMETYPE%&appID=%APP_ID%&appVersion=%APP_VERSION%&clientOS=%CLIENT_OS%&chromeLocale=%CHROME_LOCALE%), still only shows up "manual" install, not auto install.

Comment 27

10 years ago
Also, in the 2 vista and other windows XMLs, I notice that <pfs:needsRestart>true</pfs:needsRestart>

This tag should be set to "false" because no browser restart is required after JRE installation.
(Assignee)

Comment 28

10 years ago
Danielle, the .exe hosted at your URL isn't working because of some redirects occurring between http://java.com/firefoxjre_exe and the final destination.  If you change that to something direct and update the xml with that URL, you'll be able to reproduce what we have in our dev environment.

I'm not a fan of pushing this to production without testing it.  We currently have two issues:

1. http://java.com/firefoxjre_exe causes the PFS interface to timeout with a download error, something about the nature of the redirects causes Firefox to error out
2. When the URL above is a direct URL, installation works but the PFS dialog doesn't acknowledge that the external installer has started, leading the user in a quasi-state

Danielle - 1 is fixable on your end - some combination of factors is causing Firefox to produce an error -- here is a trace of what happens:
1. http://java.com/firefoxjre_exe (301)
2. http://javadl.sun.com/webapps/download/AutoDL?BundleId=18717 (302???)
3. http://sdlc-esd.sun.com/ESD39/JSCDL/jdk/6u5b/xpiinstall.exe?AuthParam=1208280806_095acb2f3ac563ff2e3f3f711819e82c&GroupName=JSC&BHost=javadl.sun.com&FilePath=/ESD39/JSCDL/jdk/6u5b/xpiinstall.exe&File=xpiinstall.exe (200, Content-Type=application/x-sdlc???)

Questions on this:
* why is #2 a 302?
* why is the final content-type application/x-sdlc?  is this right?

For our second problem with the install dialogs, we are trying to figure out why the hand off between the external installer and the PFS dialog are not working correctly.

Robert or Benjamin, do you have suggestions on how to debug this?

Comment 29

10 years ago
Hi Mike,

http://java.com/firefoxjre_exe has to be a redirect in order for us to stage different version of JRE.

In regard to your questions, it was our web engineer for java.com who set up the redirect so I don't have details on how it was done.
will send your questions to her.
I also have several questions for you:

* is there any reason that PFS can only handle 301 redirect but not 302?
* i'm not sure if our web engineer defined type="application/x-sdlc" when set up the redirect. But i thought that either content type "application/x-sdlc" or "application/octet-stream" is standard mime for .exe? If not, which content-type would you suggest us to specify for this .exe so that mimetype lookup in PFS can work?

Thanks.

Comment 30

10 years ago
I'm still waiting to hear from Mary and other web-engrs at Sun about your questions.

However, I'm curious if any chance "application/x-sdlc" was served up by nsUnknownDecoder and ExternalHelperAppService itself when FF tries to guess the content-type?

Also, I thought in the event nsUnknownDecoder fails to detect for type, either "text/plain" or "application/octet-stream" will be used.
But apparently seamonkey also complains of unknown type "application/octet-stream."

If we need to send a content-type to FF, which type should we set to if even "application/octet-stream" doesn't work?

Comment 31

10 years ago
Mike, here's answers to your questions:

> Q1: why is #2 a 302?
#2 returns a 302 because the result of calling this servlet is a redirect to the java.com's CDN (content distribution network). The CDN is where the files are actually served from. There is no way for java.com to eliminate the #2 redirect. 

> Q2: why is the final content-type application/x-sdlc?  is this right?
java.com's CDN is setup to use the mime type application/x-sdlc.  The idea is that this mime type will always be unknown to the browser, so that the browser will use 'save as' for file downloads.
One option is for java.com's web engineer to create a separate config on the CDN which doesn't declare a mime type to serve the .exe for PFS.  

While we may be able to remove the "application/x-sdlc" content-type, there's no way for us to get rid of the #2 (302) redirect.
Why do you think this intermediate redirection would cause problem? In the past, when XPI was still supported, our vanity link for XPI also involved 2 levels of redirections and PFS worked just fine.
Will PFS work if we just simply stop declaring the "x-sdlc" mimetype when serving up the file?
Your prompt response is really appreciated. Thanks. 
(Reporter)

Comment 32

10 years ago
Danielle, we're not sure why it's not working. You can test any intermediate scenarios just as well as we can ;-)

Comment 33

10 years ago
I'll see what I can do to try different scenarios.
Will keep you posted.

Updated

10 years ago
Target Milestone: 3.4 → 3.4.2
(Reporter)

Updated

10 years ago
Attachment #308582 - Attachment mime type: application/xml → text/xml

Updated

10 years ago
Target Milestone: 3.4.2 → 3.4

Updated

10 years ago
Flags: wanted1.9.0.x?
Flags: blocking-firefox3?

Comment 34

10 years ago
Created attachment 321834 [details]
Java Looping Failure screenshot

hi there, what's the latest on getting java working on PFS in production?
I just checked again, and it seems the behavior is still broken.   Searching for a java plugin is stuck in an infinite loop.   There's not even a option to install manually.   The only way the user can get java installed is to search for the plugin using other forms of searches, but not PFS.

Nominating for blocking since users cant get to java now this way.

Running Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0

Updated

10 years ago
Whiteboard: [RC2?]
(Assignee)

Comment 35

10 years ago
I suggest we fallback to the manual install URL for now while we figure this out.
(In reply to comment #35)
> I suggest we fallback to the manual install URL for now while we figure this
> out.

I would agree. Is there a bug tracking that and marked as blocking our final release?

Flags: blocking1.9.0.1?
Flags: blocking-firefox3?
Flags: blocking-firefox3-
(Assignee)

Updated

10 years ago
Depends on: 435788
(Assignee)

Comment 37

10 years ago
OK - manual installation using arrays of build IDs it is.  I filed bug 435788 to track the real issue that is messing us up here.
Flags: blocking-firefox3- → blocking-firefox3+
Whiteboard: [RC2?] → [server side]
(Assignee)

Comment 38

10 years ago
If this is blocking fx3 and 435788 can't be fixed before final, we need to reassess this.

Updated

10 years ago
Target Milestone: 3.4 → ---
Since bug 435788 can't make it, we can't block on this. We'll offer users the URL for manual install as with Flash. Morgamic - can you make sure there's a bug on that which is blocking?
Flags: blocking-firefox3+ → blocking-firefox3-
(Assignee)

Comment 40

10 years ago
bug 433592 covers this. It's checked in, scheduled to be pushed tomorrow night.
Depends on: 433592
If we're blocked here on bug 435788, and that requires new workflow/UI, then I don't see how we can take this on the branch. :(
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x-
Flags: wanted-firefox3.1+
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
Flags: blocking-firefox3.1?
(Assignee)

Comment 42

10 years ago
Mike - please not dependency on bug 435788.
Tony: can you confirm that we don't see this on Firefox 3.1? Renominate if it's still an issue. I think if it isn't, we can resolve this WFM or INVALID.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
I'm trying to test this in a VM and the installer downloaded doesn't appear to work, it says it is timing out trying to download something else. Is the url http://java.com/firefoxjre_exe sill correct?
What's the status of this?
Component: Plugins → plugins.mozilla.org
Flags: wanted1.9.0.x-
Flags: wanted-firefox3.5+
Flags: blocking1.9.0.1-
Flags: blocking-firefox3.5-
Flags: blocking-firefox3-
Product: addons.mozilla.org → Websites
Whiteboard: [server side] → [server side][pfs]

Comment 46

7 years ago
Can we close this out? Hitting this URL downloads xpiinstall.exe, which launches the java installer.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.