Closed Bug 313683 Opened 20 years ago Closed 13 years ago

Save as "Web Page, complete" fails when invalid URL is referenced in page

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: matrox77, Unassigned)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(1 file)

minimal testcase
255 bytes, text/html
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 Firefox/1.0.7 SUSE/1.0.7-0.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 Firefox/1.0.7 SUSE/1.0.7-0.1 I tried to save a webpage (complete), e.g. as 01.html with a corresponding directory 01_files. What I get is just 01_files, but no 01.html. It seems the problem is due to some figures that are not loaded. E.g., you have fig1.jpg but, fig2.gif, fig3.gif, fig4.gif, and so on... It seems these graphic files are saved in 01_files folder as a.gif, a_002.gif, a_003.gif, and so on but the JPEG file is not saved! Reproducible: Didn't try Expected Results: Mozilla should have saved the html file (say, 01.html) along with the corresponding directory (say, 01_files).
Version: unspecified → 1.0 Branch
Give us a URL to reproduce the problem.
(In reply to comment #1) > Give us a URL to reproduce the problem. The following URL allows to reproduce the problem: http://www.hihp.de/misc/webdesign/nonfunctioning.html The problem might be that it contains <body background="http://"> While that is clearly invalid, Firefox should ignore the attribute and save the rest of the webpage. Steps to reproduce: 1. go to URL 2. choose "Save as" 3. choose to save as "webpage, complete" 4. confirm operation Result: Only a directory for files is created, but nothing is actually saved. Expected result: Fiorefox should save a source HTML file and save all the used external references of the page. Reproducible: Always
Yes, I see that too, not only in Firefox but SeaMonkey from the 1.8 branch on OS/2, too.
Status: UNCONFIRMED → NEW
Component: General → HTML: Parser
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
Hardware: PC → All
Version: 1.0 Branch → 1.8 Branch
*** Bug 327944 has been marked as a duplicate of this bug. ***
Keywords: testcase
Summary: Cannot save complete webpage. directory is created but no html file. → Save as "Web Page, complete" fails when invalid URL is referenced in page
Attached file minimal testcase —
Blocks: 115634
Assignee: nobody → mrbkap
QA Contact: general → parser
Seems more like a networking issue to me. Can still be seen with the latest trunk build.
Assignee: mrbkap → nobody
Component: HTML: Parser → Networking
QA Contact: parser → networking
Version: 1.8 Branch → Trunk
I can't reproduce it with FF 3.0.4
WFM too, closing User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 SeaMonkey/2.13a1 Build identifier: 20120628003004
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
(In reply to Michal Novotny (:michal) from comment #7) > I can't reproduce it with FF 3.0.4 I cannot reproduce either in SeaMonkey 2.13a1 (equiv. Fx 16.0a1). The exact build I'm using is: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Firefox/16.0 SeaMonkey/2.13a1 ID:20120629003020 CSet: b6b7503a7ed3 http://hg.mozilla.org/mozilla-central/rev/081d8578beb1 After performing the testcase in comment #2, I see the following in the "save-to" directory: linux:~/.download/bugzilla/bug313683 # ls -alR .: total 5 drwxr-xr-x 3 root root 128 Jun 30 20:40 ./ drwxr-xr-x 6 root root 664 Jun 30 20:40 ../ drwxr-xr-x 2 root root 72 Jun 30 20:40 nonfunctioning_files/ -rw-r--r-- 1 root root 1497 Jun 30 20:40 nonfunctioning.html ./nonfunctioning_files: total 4 drwxr-xr-x 2 root root 72 Jun 30 20:40 ./ drwxr-xr-x 3 root root 128 Jun 30 20:40 ../ -rw-r--r-- 1 root root 2062 Jun 30 20:40 404.gif linux:~/.download/bugzilla/bug313683 # (Haven't tried in any earlier versions.) Resolving WFM according to advice from Philip Chee on IRC: (about comment #7): > if someone can confirm this is also the case with SeaMonkey then we can close this,
P.S. The page at the indicated URL looks like a 404 error page and I don't see any invalid URL. Its <body> tag, as shown with Ctrl+U, has no attributes of any kind. If the webmaster in question "cleaned his/her act" at some point after comment #2, then any test performed after that were invalid. I'm REOPENing the bug on that assumption. Someone, please provide an appropriate "badly constructed" HTML page, *not* anywhere on the web but as an *attachment* to this page. Then we can see if the Mozilla problem has really disappeared.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I used the wrong testcase. With the one already provided as an attachment, I see that the HTML is saved, there is no *_files directory, and when displaying the downloaded file, I see (same as with the attachment) a "broken image" icon at top left. Closing again.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: