Closed Bug 419928 Opened 12 years ago Closed 9 years ago
Location" for Java in PFS -- Windows only
1.30 KB, text/xml
1.35 KB, application/xml
107.80 KB, image/jpeg
46.91 KB, image/jpeg
48.25 KB, image/jpeg
90.76 KB, image/jpeg
66.60 KB, image/png
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.
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?
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.
Danielle - the .exe is for which versions of Windows?
What provided to you is a vanity link pointing to exe for all versions of Windows.
Here is the resulting RDF for vista.
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?
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.
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...
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
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.
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.
Attachment #314476 - Attachment description: v3, after clicking 'next' there is a download error → step 3, after clicking 'next' there is a download error
Another screenshot and confirmation from my vista machine. http://img211.imageshack.us/img211/9055/pfssniffko3.jpg
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?
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 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?
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".
(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?
When I have this as the installerLocation it fails to download every time: http://java.com/firefoxjre_exe
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.
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.
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.
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.
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.
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?
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.
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?
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.
Danielle, we're not sure why it's not working. You can test any intermediate scenarios just as well as we can ;-)
I'll see what I can do to try different scenarios. Will keep you posted.
Attachment #308582 - Attachment mime type: application/xml → text/xml
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
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?
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]
If this is blocking fx3 and 435788 can't be fixed before final, we need to reassess this.
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-
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. :(
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
Product: addons.mozilla.org → Websites
Can we close this out? Hitting this URL downloads xpiinstall.exe, which launches the java installer.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.