Another illustration of this bug: 1. Open http://www.interweb.spb.ru/present/ 2. Click on the first picture in the forth row (direct link is http://www.interweb.spb.ru/present/ex.asp?dedhorse but it may not work) This picture shows Santa Claus driving three horses. 3. You will see the same picture but of bigger size on the openned page. 4. File -> Save Page As... -> Web Page, complete 5. There is no image of the picture among saved files
We save <embed> and <object>... Should that code just be tweaked to save <applet> too? If so, which attrs of it should we persist? That is, which attributes point to the data that needs to be saved?
you can't really know :). an applet might use a random attribute to reference external resources to be loaded by it :).
Sure. We're trying to do the common case here.
http://www.w3.org/TR/html4/struct/objects.html#h-13.4 sounds like the "code" attribute is to be saved, using codebase as base uri. I do think we should save java applets.
Created attachment 172606 [details] [diff] [review] Patch Could someone who actually has Java installed give this a spin?
Comment on attachment 172606 [details] [diff] [review] Patch OK, I can't find a way to test this (Java won't run with my builds), but this should be the right thing....
I built Firefox with this patch, rolling a debug suite if needed. On startup I get the folowing error in the JS console. Error: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: file:///E:/build/components/nsDefaultCLH.js :: clh_handle :: line 81" data: no] Source File: file:///E:/build/components/nsDefaultCLH.js Line: 81 Saving pages does include java applets. If the saved page is loaded into Firefox the java applet is not loaded. If you need a copy of the build (windows/cygwin/visiual studio) send me an email.
The JS error is a Firefox bug. Please file it and make sure to cc bsmedberg (":bs" will match him). I took another look at this applet, and it looks like we need to persist the "archive" attribute too. Further, we would need to persist param values that are URIs... except we have no way to tell which of them are URIs. So I'll settle for just persisting "code" and "archive" and seeing how that works...
So... I don't see why the applet works. The markup is: <applet code=ansnow archive=Ansnow.jar width=620 height=375 codebase=/applets/anfy> Resolving the URIs, the codebase is: http://www.interweb.spb.ru/applets/anfy and the archive attribute points to: http://www.interweb.spb.ru/applets/Ansnow.jar wheareas on the site, the Ansnow.jar file is at: http://www.interweb.spb.ru/applets/anfy/Ansnow.jar So when we try to save the file we get a 404, and save nothing....
Created attachment 173780 [details] [diff] [review] This should work in general, but I need a site to test it on...
Attachment #172606 - Attachment is obsolete: true
14 years ago
I rebuilt firefox with the new patch, the java files were saved. I was still unable to reopen the local copy of the page and get the java to load.
Kevin, which page did you test on?
Created attachment 175067 [details] Trace of loading local java applet I have tried it on the bug's URL, http://theskishopplus.com/ and http://www.java.com. When loading the local version of the page the status bar says "Applet (name of applet) notinited" and once you move the mouse over the applet it says "Loading Java Applet Failed". I added an attachment with the Java console trace from the bug's URL as that one looked the simplest.
Kevin, please don't use the testcase in the bug's url until we have this working elsewhere. See comment 10 for the reason -- it just seems to be miscoded (and it's still not clear to me why it works to start with). I just tried saving http://theskishopplus.com/ and the applet data is saved correctly. The data pointed to by some of the <param> elements is not saved, but that's because we have no way to tell whether a <param> points to a url. For some of them, I can't even tell it by looking at the source, so there's really no way the browser could do it... We just pass all the param values as strings to the applet, and the applet does something with them.... With java.com, I do see a problem. Let me try to figure out why it happens...
Created attachment 175087 [details] [diff] [review] Slightly updated Again, this doesn't help with the URL in the URL field, but it should help with java.com (which does put the requisite '/' at the end of its codebase). I did some checking, and the testcase in the URL field relies in buggy URI resolution in the Java applet itself.... There's no really good way for us to duplicate it, and no reason to try. So asking for reviews. This won't help with pages that pass relative URIs in <param>s, and it won't help with pages like the one in the URL field, but it'll help with sane pages...
Comment on attachment 175087 [details] [diff] [review] Slightly updated ok... this code duplication isn't so nice (but it seems to be done for some other cases too)... can you file a bug on that? + // Unset the codebase to, since we'll correctly relativize the the "to" looks like a typo?
Attachment #175087 - Flags: review?(cbiesinger) → review+
Comment on attachment 175087 [details] [diff] [review] Slightly updated sr=jst
Attachment #175087 - Flags: superreview?(jst) → superreview+
14 years ago
Assignee: file-handling → bzbarsky
Fixed with biesi's comment addressed. Note that the testcase in the URL field is not fixed, because I see no way to possibly fix it... the java.com testcase should be fine, though.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.