Closed Bug 114874 Opened 23 years ago Closed 23 years ago

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

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bugzilla3, Assigned: bugs)

References

Details

(Keywords: regression, smoketest)

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).
Severity: normal → major
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. ***
Keywords: regression
> 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
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
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
Closed: 23 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. ***
*** Bug 115015 has been marked as a duplicate of this bug. ***
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.
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!
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
Closed: 23 years ago → 23 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 → ---
0744 is fine
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.
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.
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...
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
Closed: 23 years ago → 23 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
*** Bug 115320 has been marked as a duplicate of this bug. ***
*** Bug 115493 has been marked as a duplicate of this bug. ***
Blocks: 115634
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.