If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Save Page As fails (blank new window, no file creation)

VERIFIED FIXED

Status

Core Graveyard
File Handling
--
blocker
VERIFIED FIXED
16 years ago
a year ago

People

(Reporter: Dimitrios, Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

({regression, smoketest})

Trunk
regression, smoketest

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
After fixing bug 11632, we have a nice selection for saving a complete page (a
la IE5). Content sniffing seems to be ok, dialog for saving the files is working
but after clicking ok I only see a blank new window (no menus or title bar)
created and no files saved on disk. No hang or crash, just a new useless window :(
Reproducible always. Tested on modern and classic theme, new profile. Build
2001121203, Win98.
Leaving it unconfirmed, in case I did something blatantly wrong (it seems
strange for such a long awaited feature not to working at all).
(Reporter)

Updated

16 years ago
Severity: normal → major
(Reporter)

Updated

16 years ago
Summary: Save Page With Images fails (blank new window, no file creation) → Save Page As fails (blank new window, no file creation)
to ben. people are definitely seeing this...
Assignee: law → ben
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 114880 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Keywords: regression

Comment 3

16 years ago
> after clicking ok I only see a blank new window

Don't know what that's about, after I click *Save*, the dialog disapears and the
page remains where I was at.
OS: Windows 98 → All
Hardware: PC → All

Comment 4

16 years ago
On WinME 2001121203 I see the following:
1. Select File/Save Page As...
2. Type filename, press save button
3. Look in directory I saved to, nothing there.
this is a blocker --i cannot save at all.
Severity: major → blocker
Keywords: smoketest

Comment 6

16 years ago
Reading the smoketest list (http://www.mozilla.org/quality/smoketests/), saving
a page is not a smoketest.

This is definitely a blocker, though. Removing smoketest keyword.
Keywords: smoketest
also see this with commercial builds, with a difference: the file picker doesn't
even pop up. had filed http://bugscape.mcom.com/show_bug.cgi?id=11407, but it
might prolly be a dup of this bug.

sorry, hwaara, this blocks my testing and use of this feature, which is pretty
basic.

if leaf thinks this shouldn't hold up the tree, then i'll let him make that
decision. :)
Keywords: smoketest
*** Bug 114905 has been marked as a duplicate of this bug. ***
looking. 
Status: NEW → ASSIGNED
oh my. looks like the file shifted but the old one was not removed. copied 
code over to the correct one. rebuilding...
fix checked in. 
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
tested saving [all three choices: entire page, html and txt] with the
2001.12.12.21 mozilla bits on linux rh7.2 --but still doesn't work.

get the following error in the js console:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80570018 (NS_ERROR_XPC_BAD_IID) [nsIJSCID.createInstance]"  nsresult:
"0x80570018 (NS_ERROR_XPC_BAD_IID)"  location: "JS frame ::
chrome://communicator/content/contentAreaUtils.js :: makeWebBrowserPersist ::
line 379"  data: no]

reopening.

note: this is working for ben on two win32 boxes --this might be linux-only...
Status: RESOLVED → REOPENED
Keywords: pp
OS: All → Linux
Hardware: All → PC
Resolution: FIXED → ---
*** Bug 114995 has been marked as a duplicate of this bug. ***

Comment 14

16 years ago
*** Bug 115015 has been marked as a duplicate of this bug. ***

Comment 15

16 years ago
ummm... this works on a fresh CVS, linux.
With a somewhat unexpected result:

I saved this very page as "web page, complete.." and it landed in a new
directory called "file:" where it started to reconstruct my homedir, so files in
reality now landed in /home/dark/file:/home/dark/thisbug.html
An accompanying subdir: thisbug_files was also created and i can't cd into it
because it has wrong file permissions set:
drw-r--r--    2 dark     dark         4096 des 13 11:13 thisbug_files

It should have had the x bit set for owner of course.
Changing chmod u+x on it and cd'ing into the dir: It's empty. No images/files
were saved.

Right-clicking a link and saving page as "web page, html only" works fine.

Comment 16

16 years ago
R.K.Aa: I also see that with PC Linux 2001121221.
saving a single file as HTML fails as well.  You still get the
file:/full/path/to/file filename rooted in the current directory instead of just
having the file get saved to the current directory.

Did someone forget a "//" after "file:" somewhere?
re: comment 15: fwiw, i had tried to save the file to /tmp/foo/ rather than my
home dir... recently checked both my home dir and the moz install dir, but
couldn't find a new subdir called 'file:'... hmmm...

in any case, i'll be away till this afternoon...if there's a[nother] workaround,
feel free to downgrade this. thanks!

Comment 19

16 years ago
This still doesn't work for me on WinME 2001121303.  "Save Page As" brings up
the dialog, but doesn't save any files, and "Save Link As" doesn't even bring up
the dialog.  I also tried a new profile and that didn't work either.
The embed_base.xpt file which contains nsIWebBrowserPersist was not being 
packaged in release builds, it seems. 

Fix checked in. 
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
Ben, does that fix affect non-installer builds?  I installed from .tar.gz;
R.K.Aa built from CVS, as her comment says.
In particular:

http://lxr.mozilla.org/seamonkey/source/embedding/components/ui/progressDlg/nsProgressDlg.js#403

has:  filesFolder.create(lfIID.DIRECTORY_TYPE, 0644);

That should be a 0755 if you want to create a usable directory (like one that
you can actually write things to).  Reopening this.  As is, save page cannot
possibly work on Linux.



Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 23

16 years ago
0744 is fine

Comment 24

16 years ago
Can someone to verify this build (it includes Ben's fix) if it fixes this bug.

ftp://sweetlou.mcom.com/products/client/seamonkey/unix/linux/2.2/x86/2001-12-13-
12-trunk/

and let us know the result please.  Thanks.

Loan
That build has the behavior described in comment 15 and comment 17.  No, not fixed.
I don't think this build has my change. the embed_base.xpt file is not in
components as it should be. 

Comment 27

16 years ago
Ben, I checked out your changes and did a linux depend build.  Is there anything 
that I need to remove manually when doing this build?  If I do a clobber build, 
then it will take for a while.  

Fyi, I'm also doing win32 clobber build, and it will take at least 3 hours to 
complete.
It is here.  As I said, I'm using the .tar.gz build, not one of the installer
builds.
using the 2001.12.13.12 comm bits on linux rh7.2, i still get the same results
[failure] as in comment 18. i used the stubs installer, custom installation
[didn't install java].

here's the js console output i get when trying to do a File > Save Page As [all
content]:

Warning: reference to undefined property children[0]
Source File: chrome://global/content/filepicker.js
Line: 507

Warning: reference to undefined property Components.interfaces.nsIWebBrowserPersist
Source File: chrome://communicator/content/contentAreaUtils.js
Line: 378

Error: uncaught exception: [Exception... "Component returned failure code:
0x80570018 (NS_ERROR_XPC_BAD_IID) [nsIJSCID.createInstance]"  nsresult:
"0x80570018 (NS_ERROR_XPC_BAD_IID)"  location: "JS frame ::
chrome://communicator/content/contentAreaUtils.js :: makeWebBrowserPersist ::
line 379"  data: no]
filed bug 115132 for the 'file:/<path>' issue, which ben says is different from
this one.

Comment 31

16 years ago
Ben checked in the fix again.  Linux build completed.  Can someone help to test 
it

ftp://sweetlou.mcom.com/products/client/seamonkey/unix/linux/2.2/x86/2001-12-13-
14-trunk/

Let me know the result so I can open the tree.

Thanks,
Loan
This is related to my checkin, but I don't think this is my bug. The correct 
xpt file (webbrowserpersist.xpt) is specified in the packager file but it is 
not showing up in installer builds. It doesn't look like this is the only xpt 
file that is missing, according to packages-unix. There appears to be excess 
newlines in the [browser] sectino of that file which I've just removed. This 
should probably go to an xpinstall person. 
okay, i can now save files using the 2001.12.13.14 comm bits on linux. [other
than encountering bug 115132].
Keywords: pp
OS: Linux → All
Hardware: PC → All
win32 bits work fine now! test with 2001.12.13.16 comm bits on winNT.

side note #1: for anyone here on Mac [X or 9.x] Save Page is still broken, but
that's covered by bug 107521.

side note #2: save as text not working [still get html source] is bug 42441.
This only works on Linux as long as you're not trying to save the HTML _and_ the
images.  Just the HTML saves fine modulo bug 115132.  Not saving the images is
bug 115154.
correction on my previous comment, note #1 --bug 107521 covers filters not
working on Mac. i'll need to test tomorrow's mac bits to make sure the default
Save Page behavior works...

Comment 37

16 years ago
pretty nice work! 

A couple of nits, though...

using build 2001121313 on Win2k (SP2)

1. files referenced by css, such as backgrounds using the following syntax are 
ignored, thereby skipping some files that should be downloaded:

body {
  background : transparent url(./images/mybackground.gif) repeat-y scroll left;
}

I imagine this would also apply to stylesheet linked using @import which are 
inside a parent stylesheet that is linked in the document using the html LINK 
tag (actually, would a file be downloaded if an @import is used between html 
STYLE tags???).

2. When I downloaded my own page ( http://www.visi.com/~hoju/indextest.html ), 
I noticed that the html is saved in an invalid way.  The doctype is not saved 
on a line by itself.  Rather, the opening HTML, HEAD, and TITLE tags are 
written on the same line as the doctype.  this might be because line feeds 
chars are of a UNIX type and not in DOS format as they should be when written 
on Windows.  Not sure if the two problems are related but, regardless, they are 
both problems.

Should these be reported as separate bugs?  Otherwise, things work pretty 
nicely :-)

Jake
Item 1 is already filed.  search for bugs filed today on ben.

Item 2 is not filed, should be a separate bug if you file it, and I don't think
that putting the stuff on the same line produces invalid HTML.  I just tried
running such a document (with the xml-version PI, doctype, <html><body> all on
one line) through the W3C validator and it validates fine.
All bugs relating to the actual file that is saved (format of the document, 
objects that are saved with it, and any glitches therein) should be given to 
adamlock@netscape.com, as he is the owner of the webbrowserpersist component 
that this front end work exposes ;)

bugs to do with the file picker, filter list, and the place where the files 
are saved should be given to me

Judging by the latest respins, I think the inability to save anything at all 
is now fixed. 
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
*** Bug 115250 has been marked as a duplicate of this bug. ***
...and vrfy'd fixed on mac 10.1.1 and 9.1 with 2001.12.14.04 comm bits --tested
with Save Link and Save Image [via context menu], since Save Page is blocked by
bug 107521.
Status: RESOLVED → VERIFIED

Comment 42

16 years ago
*** Bug 115320 has been marked as a duplicate of this bug. ***

Comment 43

16 years ago
*** Bug 115493 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Blocks: 115634
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.