From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8) Gecko/20020204 BuildID: 2002020406 After copying and pasted an <img src=...><br><br> line in the HTML source editor view, and then switching to normal mode, all the images which are hyperlinked in that file become truncated to 16kB. The images are lost forever, because they have been overwritten by Mozilla. They are all exactly 16.0kB. This kind of sounds like the behaviour of the LoveLetter.VBS virus actually, but I definitely do not have this virus, as I have scanned my drives using the latest update of my virus checker. And the images would probably have .vbs extensions added if it really was the LoveLetter.vbs virus. Reproducible: Always Steps to Reproduce: This what I do: 1. I have a file with 8 links to images. I want to add another which is similar to the others. Switch to HTML source mode. 2. Copy and paste the line that says: " <img src="assn4page9.gif" alt="Assignment #4 Page #9" width="850" height="1086"><br><br> 3. So there are now 2 lines which link to assignment 4 page 9. 4. Switch back to normal mode in composer. All the images appear as little strips, so only the very top of the image is shown. 5. Go to Windows Explorer, notice that all the images linked in that .html file are now 16kB large. 6. Sometimes, just copying and pasting the link isn't enough to make it happen. If it doesn't happen, second the second img src= to point to assn4page2.gif, but leave the alt-text the same, that will do it. Actual Results: The images were all reduced to 16kB images. Data lost! Expected Results: It shouldn't have messed up my images.

This seems to me that it is a dupe of bug 121980. I am resolving as such. Reporter, if you feel that this is a different issue, feel free to reopen this bug. *** This bug has been marked as a duplicate of 121980 ***

I think Michael may be correct in dupping this. To check, look at HTML source after switching from source view to "normal". Are the URLs for the images now different than they were? If yes, that is probably the problem. Comments I thought of before Michael dupped this may still apply: This is not something Composer could be doing to your images. All Composer does is let you change the image SRC; the display of the image is done by the gecko layout engine. Can you reproduce the problem by simply adding the extra link in the "Normal" (HTML editing) mode, then save the page, close app, restart the app and load the same page? Also try editing the HTML source just as you did in a text editor like notepad. Save the source and load into mozilla browser and editor. Any problems?

reopen bug this bug is for truncation issues

-->brade I haven't noticed any problem on my Macintosh builds (other than the image files being rewritten)

I can confirm that this happens on my 0.9.8 Linux build. Images have to be bigger than 16k to be effected (16,384, to be precise). Here's what happens: 'testdir' is an empty directory. 'imagedir' has some images (jpg, gif, png, doesn't matter) in it. * In Composer insert an image on to a new page and save it in 'testdir'. - Notice that testdir now has your html file and a (possibly renamed) copy of your image file. - Also note that the html generated does not point at this new image, but at the original. * Repeat if you want to. * Go into HTML Source mode, change the URLs in the IMG tags to point at the copies now in the testdir directory. * Save file. All images that were larger than 16K, have been truncated down to 16K. What should happen? It seems to me that composer should never manipulate images at all. If I insert an image, then composer should simply generate code such as <img src="../imagedir/imagefile.jpg"> (not, btw, file:////path/to/image), and be done with it. The file copying and renaming (logo-alpha-1.jpg will be renamed logoalpha1.jpeg for some reason during the copy) are really bug 121980, as noted. The truncation thing is this bug. UA: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 OS: RedHat Linux 7.1

I see this bug. I can reproduce it in the browser with these steps: * open remote page in Browser * save complete * open saved html file in Browser window * save complete (replacing existing files) plus I also see a nasty crash I have a possible fix in my tree which I hope to test early tomorrow.

Thanks for everyone's involvement. This was my first bug submit, and it's getting some attention from a few people so I'm impressed. I'm just wondering what is a workaround for this with 0.9.8 right now. I'm scared to edit my *.htm files in Composer, but is there a way I can do it without having them all reduced/replaced to 16kB files? Thanks.

Unfortunately, I don't know of a workaround using the 0.9.8 build. I would suggest getting a newer build (from yesterday?) and avoiding the few scenarios in Composer where this might bite you.

This patch does the uri comparison so it doesn't overwrite image files; however, I am seeing bad crashes when I save in the browser (during JS' GC). These are the steps I do (and I see the crash with and without my patch): * open file with images (on web server; not local) in navigator window * Save Complete to a junk folder * open the resulting (saved, local) file in a navigator window * do Save Complete again into same location (same file name) * if crash hasn't happened, it does when closing the navigator window. I don't see anything lurking in my tree that would cause this problem but I also don't see the problem when using an optimized nightly build from yesterday. Ideas?

This patch is similar to above but improved. It now waits for OnStart notification so we can be sure to have the server's response for contentType before determining extension. It also moves the redirect checking (to be consistent); Darin assures me that the redirect will have happened by this point so this shouldn't cause any problems. Lastly, this patch fakes a Stop state so listeners will get both start/stop for every file (including ones that match and aren't saved).

This patch is same as above except it doesn't send the simulated (duplicate) stop event.

Comment on attachment 70367 [details] [diff] [review] patch that is even cleaner r=adamlock Get rid of sendFakeStopState. Probably you don't need to set isEqual to PR_FALSE if the Equals method failed

Comment on attachment 70367 [details] [diff] [review] patch that is even cleaner >Index: mozilla/embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp > >+ nsCOMPtr<nsIChannel> channel = do_QueryInterface(request); nsCOMPtr<nsIChannel> channel( do_QueryInterface(request) ); is preferred since it will call the copy constructor instead of the assignment operator. most compilers will optimize both to the same things, but it's better to not depend on that ;-) >+ // compare uris and bail before we add to output map if they are equal >+ PRBool isEqual = PR_FALSE; >+ if (NS_FAILED(data->mFile->Equals(data->mOriginalLocation, &isEqual))) >+ isEqual = PR_FALSE; setting isEqual to FALSE is good defensive programming because you cannot trust any out parameters after a XPCOM method throws an exception. nice job cleaning up the LITERAL string fu :-) sr=darin

fix checked in

David, please verify in tomorrow's 2/20 build and then mark this bug accordingly..mark it verified-fixed... thanks.

Do you need me to mark it verified? I'm out of town right now, and away from my computer... If someone else can verify it tomorrow though, that's fine with me. It sounds like you guys got a handle on this bug though. Thanks everyone!

I checked it out on Windows 98, which is where I did most of the initial "bug discovering before". It

Sorry, that was verified under nightly build 2002022203 for Windows 98

Can someone please mark this as resolved?

Oops, sorry, I'm not up on the terminology. I meant to say "can someone mark this as closed-fixed" Thanks.

maybe I can set the closed status myself. here goes