Closed Bug 121980 Opened 23 years ago Closed 23 years ago

Composer saves images with html page (in wrong location)

Categories

(SeaMonkey :: Composer, defect)

defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: philippe.mignard, Assigned: Brade)

References

Details

(Whiteboard: EDITORBASE+ QAHP)

Attachments

(2 files)

Tested with Build 2002012503 Open a page in composer, then select "Insert Image", and choose an image in ANOTHER directory. The save and close the page and open the directory: the image has been copied in the directory where html page resids. Moreover, if the source image was in the same directory, the new image replaces the old one, with the possibility of errors (and the result is desastrous with loss-compression images like jpeg). Thanks
-->brade (Adam--yes, Composer is using persist)
Assignee: syd → brade
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
Summary: Composer saves images with html page → Composer saves images with html page (in wrong location)
Target Milestone: --- → mozilla0.9.9
heads up tucson.
Keywords: nsbeta1
Whiteboard: EDITORBASE QAHP
Definitely a problem, it overwrote a file of the same name with the image file without allowing me to make a choice. Marking EDITORBASE+
Keywords: nsbeta1nsbeta1+
Whiteboard: EDITORBASE QAHP → EDITORBASE+ QAHP
The source of the problem is that we are using the new nsIWebBrowserPersist interface, which saves associated image files. FYI: For composer, we are setting the location for images as the same as the page. When saving from Browser, they seem to put images in a subdirectory under the page with a name = filename+"_files". Is that by design? We need to add the same "file type option" used by browser in the save dialog so user canc choose to save image files or not. (This will be a problem for Mac, which doesn't show the dropdown menu for "file types") It seems to me that the default, which is currently to always save images, should be to save images only when saving a remote file. Obviously we need to add an overwrite file warning when saving images so we don't do that without user permission; we should check file location (and maybe the timestamp?) to avoid saving an identical file on top of itself. I don't think the "(in wrong location)" in the summary is incorrect though; using the page location is probably the correct default thing to do when saving a remote file's associated images.
Status: NEW → ASSIGNED
I believe this affects external CSS files as well. http://bugzilla.mozilla.org/show_bug.cgi?id=115107 Makes editing a website difficult.
*** Bug 124625 has been marked as a duplicate of this bug. ***
This patch doesn't do the "complete" saving when saving locally unless you choose Save As and pick a different directory. (Save As... in the same directory (rename of file) does not adjust image locations.)
Comment on attachment 69040 [details] [diff] [review] don't move images when saving local files except on saveAs okilee dokilee
Attachment #69040 - Flags: review+
Comment on attachment 69040 [details] [diff] [review] don't move images when saving local files except on saveAs sr=kin
Attachment #69040 - Flags: superreview+
When we are doing SaveAs, will the SRC urls in the <img> elements still be changed to absolute or are they left as relative?
absolute vs relative url issue is handled in a different bug
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Philip, please retest and let us know if this is fixed for you now in latest build. thanks.
The bug seems to be resolved in release 2002021203, except in one case: if you create a new page, then insert an image (or choose an image background), and save the page. The image is saved locally as the link is kept onto the image (note it can't be relative because Relative URL is desabled because the page is not saved again). But if the image is in the same directory you saved the page, the new image again replaces the old one. So the bug isn't completely fixed. In the other cases, the images are not saved anymore.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch handle the "new" page case (deleted) — Splinter Review
Oops! I must have forgotten about the case where the user is not editing locally or remote (about:blank). This adds that case. reviews please :-)
Comment on attachment 69531 [details] [diff] [review] handle the "new" page case r=cmanske
Attachment #69531 - Flags: review+
fix checked in; (sr from Kin on aim)
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Phillipe, please verify whne you get chance...thanks.
*** Bug 126401 has been marked as a duplicate of this bug. ***
Verified on Win XP using build 2002021803. If anyone is still seeing this issue feel free to reopen this bug.
Status: RESOLVED → VERIFIED
*** Bug 126663 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: