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

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Max Alekseyev]

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

Comment 1

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

there is no javascript involved. fixing summary.

(I can't find the mentioned link on http://www.interweb.spb.ru/present/... but
the direct link worked)

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

[timeless]

you can't really know :). an applet might use a random attribute to reference
external resources to be loaded by it :).

Comment 4

[Boris Zbarsky [:bzbarsky]]

Sure.  We're trying to do the common case here.

Comment 5

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

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

Could someone who actually has Java installed give this a spin?

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Kevin Brosnan]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: This should work in general, but I need a site to test it on...

Comment 12

[Kevin Brosnan]

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.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Kevin, which page did you test on?

Comment 14

[Kevin Brosnan]

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

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

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

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?

Comment 18

[Johnny Stenback (:jst)]

Comment on attachment 175087 [details] [diff] [review]
Slightly updated

sr=jst

Comment 19

[Boris Zbarsky [: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.