Save Page As "Web Page, complete" does not save Java applets



14 years ago
2 years ago


(Reporter: relf, Assigned: bzbarsky)



Firefox Tracking Flags

(Not tracked)




(2 attachments, 2 obsolete attachments)



14 years ago
Another illustration of this bug:

1. Open

2. Click on the first picture in the forth row (direct link is 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
there is no javascript involved. fixing summary.

(I can't find the mentioned link on but
the direct link worked)
Summary: Save Page As "Web Page, complete" does not save Javascript generated image → Save Page As "Web Page, complete" does not save Java applets
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?

Comment 3

14 years ago
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. 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]

Could someone who actually has Java installed give this a spin?
Comment on attachment 172606 [details] [diff] [review]

OK, I can't find a way to test this (Java won't run with my builds), but this
should be the right thing....
Attachment #172606 - Flags: superreview?(jst)
Attachment #172606 - Flags: review?(jst)

Comment 8

14 years ago
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:

and the archive attribute points to:

wheareas on the site, the Ansnow.jar file is at:

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
Attachment #172606 - Flags: superreview?(jst)
Attachment #172606 - Flags: superreview-
Attachment #172606 - Flags: review?(jst)
Attachment #172606 - Flags: review-

Comment 12

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?

Comment 14

14 years ago
Created attachment 175067 [details]
Trace of loading local java applet

I have tried it on the bug's URL, and 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 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, 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 (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...
Attachment #173780 - Attachment is obsolete: true
Attachment #175087 - Flags: superreview?(jst)
Attachment #175087 - Flags: review?(cbiesinger)
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

Attachment #175087 - Flags: superreview?(jst) → superreview+
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 testcase
should be fine, though.
Last Resolved: 14 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.