not quite the same as bug 176020. found using 20050217 trunk seamonkey builds. I've seen this on Mac and Windows. Tracy, did you see this on linux? 1. open a new composer window. 2. insert an image. results: instead of seeing the image inline, I see the broken image icon. note: this isn't a problem when browsing that file in a browser, or after closing then reopening the file in composer.

I'm not seeing this on any platform.

weirdness.

steps to reproduce: 1. open a new composer window. 1a. save document 2. insert an image. JS Console says: Security Error: Content at about:blank may not load or link to file:///home/andrew/name.html. terminal console says: [Exception... "Access to restricted URI denied" code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)" location: "chrome://editor/content/editor.js Line: 508"] this regressed between 1.7 and 1.8a1. I'll narrow it down more later if needed.

As a note, I only see it if the relative URL box is checked (which is the default). If I uncheck it and use the absolute URL, it works... Switching an image that was insterted with absolute URL back to relative URL afterwards works though and doesn't break image display.

That error is caused by the function trying to update the document's base URI from about:blank to whatever you saved it as. And without a correct base URI you can't use relative paths in images.

OK, so part of the bug is that nsDocument::SetBaseURI use the cached principal for the old URI which causes nsDocument::SetBaseURI(nsDocument::GetDocumentURI) to fail the security check. However, it's unnecessary to do this.

Hmm... actually, I'm not so sure... I thought it would be safe to call [nsIDocument] doc->SetBaseURI(nsnull); - it seems to work, but is it right?

Now I'm getting confused... mPrincipal is cleared when the URI is changed...

Comment on attachment 180582 [details] [diff] [review] Clear the cached principal when we reset the document location I don't really have a good feel for the security implications of this (esp. as regards Midas, where a location change can be triggered by untrusted content)....

Comment on attachment 180582 [details] [diff] [review] Clear the cached principal when we reset the document location I'm not sure that change is actually right; for example if the document has a certificate principal we'll lose that information. Do we ever hit this code for Midas documents on the web?

I'm seeing this same behaviour in Thunderbird 1.3a1 20070110 and it has been for a long time. It is very annoying.

In short, inserting an inline image in Thunderbird 1.3a1 seems to break if: 1. You start composing a message and save the message. 2. You start composing a message replying to a message you've received. 3. You start composing a message and do some edits in the text body of it (sometimes - does it auto-save after some delay?). Or should I be opening a new bug number against thunderbird for this?

(In reply to comment #13) > Or should I be opening a new bug number against thunderbird for this? David Campbell found bug 346835, which was filed under TB -- but I'm about to move it to Core, as it's reproducible for Seamonkey mail composer as well. Like that bug: if you save the file with the broken image, then reopen it, the image appears as expected. On my initial testing, tho, there seems to be a difference: once I reopened, I couldn't reproduce the symptom again in the same file -- every subsequent Save + Insert|Image displayed the new image as expected; whereas in mail, a reopened draft does exhibit the symptom.

Comment on attachment 180582 [details] [diff] [review] Clear the cached principal when we reset the document location Removing request that I don't plan to follow up. Neil, you might want to get peterv to look at this or something...

Neil, daniel, peterv, Are you still working on this ?

Can't reproduce this on trunk, closing as WFM User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 SeaMonkey/2.13a1 Build identifier: 20120712003002