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

Status: RESOLVED FIXED

(Websites :: plugins.mozilla.org, defect)

Description

[Benjamin Smedberg]

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

[danielle.pham]

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

[danielle.pham]

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.

Comment 3

[Michael Morgan [:morgamic]]

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

Comment 4

[danielle.pham]

What provided to you is a vanity link pointing to exe for all versions of Windows.

Comment 5

[Michael Morgan [:morgamic]]

Attachment: vista rendered RDF

Here is the resulting RDF for vista.

Comment 6

[Michael Morgan [:morgamic]]

Attachment: RDF for other versions of Windows

Comment 7

[Michael Morgan [:morgamic]]

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

[danielle.pham]

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.

Comment 9

[Michael Morgan [:morgamic]]

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

[Tony Chung [:tchung]]

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

Comment 11

[Michael Morgan [:morgamic]]

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.

Comment 12

[Michael Morgan [:morgamic]]

Attachment: step 1, nothing unusual

Comment 13

[Michael Morgan [:morgamic]]

Attachment: step 2, got the install window as expected

Comment 14

[Michael Morgan [:morgamic]]

Attachment: 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.

Comment 15

[Tony Chung [:tchung]]

Another screenshot and confirmation from my vista machine.   

http://img211.imageshack.us/img211/9055/pfssniffko3.jpg

Comment 16

[Michael Morgan [:morgamic]]

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?

Comment 17

[Michael Morgan [:morgamic]]

Attachment: 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?

Comment 18

[Michael Morgan [:morgamic]]

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?

Comment 19

[Benjamin Smedberg]

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".

Comment 20

[Michael Morgan [:morgamic]]

(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?

Comment 21

[Christian :Biesinger (don't email me, ping me on IRC)]

nsIDownloader should transparently follow redirects. is that not what you're seeing?

Comment 22

[Michael Morgan [:morgamic]]

When I have this as the installerLocation it fails to download every time:
http://java.com/firefoxjre_exe

Comment 23

[Tony Chung [:tchung]]

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.

Comment 24

[Benjamin Smedberg]

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

[Tony Chung [:tchung]]

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

[danielle.pham]

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

[danielle.pham]

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.

Comment 28

[Michael Morgan [:morgamic]]

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

[danielle.pham]

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

[danielle.pham]

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

[danielle.pham]

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. 

Comment 32

[Benjamin Smedberg]

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

Comment 33

[danielle.pham]

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

Comment 34

[Tony Chung [:tchung]]

Attachment: 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

Comment 35

[Michael Morgan [:morgamic]]

I suggest we fallback to the manual install URL for now while we figure this out.

Comment 36

[Mike Beltzner [:beltzner, not reading bugmail]]

(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?

Comment 37

[Michael Morgan [:morgamic]]

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.

Comment 38

[Michael Morgan [:morgamic]]

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

Comment 39

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 40

[Michael Morgan [:morgamic]]

bug 433592 covers this. It's checked in, scheduled to be pushed tomorrow night.

Comment 41

[Mike Beltzner [:beltzner, not reading bugmail]]

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. :(

Comment 42

[Michael Morgan [:morgamic]]

Mike - please not dependency on bug 435788.

Comment 43

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 44

[Dave Townsend [:mossop]]

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?

Comment 45

[Wil Clouser [:clouserw]]

What's the status of this?

Comment 46

[Kev Needham [:kev]]

Can we close this out? Hitting this URL downloads xpiinstall.exe, which launches the java installer.