121980 - Composer saves images with html page (in wrong location)

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[Philippe Mignard]

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

Comment 1

[Kathleen :Brade]

-->brade
(Adam--yes, Composer is using persist)

Comment 2

[sujay]

heads up tucson.

Comment 3

[Syd Logan]

Definitely a problem, it overwrote a file of the same name with the image file
without allowing me to make a choice. Marking EDITORBASE+

Comment 4

[Charles Manske]

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.

Comment 5

[Rafael Ebron (:rebron)]

I believe this affects external CSS files as well. 
http://bugzilla.mozilla.org/show_bug.cgi?id=115107

Makes editing a website difficult.

Comment 6

[michael wendell]

*** Bug 124625 has been marked as a duplicate of this bug. ***

Comment 7

[Kathleen :Brade]

Attachment: don't move images when saving local files except on saveAs

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 8

[Joe Francis]

Comment on attachment 69040 [details] [diff] [review]
don't move images when saving local files except on saveAs

okilee dokilee

Comment 9

[kinmoz]

Comment on attachment 69040 [details] [diff] [review]
don't move images when saving local files except on saveAs

sr=kin

Comment 10

[Charles Manske]

When we are doing SaveAs, will the SRC urls in the <img> elements still be 
changed to absolute or are they left as relative?

Comment 11

[Kathleen :Brade]

absolute vs relative url issue is handled in a different bug

Comment 12

[sujay]

Philip, please retest and let us know if this is fixed for you now
in latest build. thanks.

Comment 13

[Philippe Mignard]

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. 

Comment 14

[Kathleen :Brade]

Attachment: handle the "new" page case

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 15

[Charles Manske]

Comment on attachment 69531 [details] [diff] [review]
handle the "new" page case

r=cmanske

Comment 16

[Kathleen :Brade]

fix checked in; (sr from Kin on aim)

Comment 17

[sujay]

Phillipe, please verify whne you get chance...thanks.

Comment 18

[R.K.Aa.]

*** Bug 126401 has been marked as a duplicate of this bug. ***

Comment 19

[michael wendell]

Verified on Win XP using build 2002021803.

If anyone is still seeing this issue feel free to reopen this bug.

Comment 20

[R.K.Aa.]

*** Bug 126663 has been marked as a duplicate of this bug. ***