I found this problem while testing my fix for bug 77053. If you don't crah the first time you view the message, try a second time :-) 1) Open a compose message window 2) Attach the web page www.marketwatch.com (use the file/attach page), You need to use a build that have the fix for bug 77254 3) Send the mesage to yourself 4) Receive the message 5) Click on it to see it 6) ==> CRASH in MimeStreamComverter because we are trying to process a null URL!!! If you are not crashing, select another message and then select again the message.

nominating nsbeta1

I tried a build from 2001041212 and it works fine but the build from 2001041304 crash when viewing this page for the second time. It really looks like a regression of mscott cache landing on 04/12 at 20:48. Reassign to mscott

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

marking nsbeta1+

This crash is very similar to one we used to have involving relative image urls. In this case, we have a relative path to a style sheet. The style system is ignoring the BASE URL tag we are emitting which points to http://www.marketwatch.com and instead attempts to resolve the relative link for the style sheet on the imap url used to display the message. Of course this causes us to think we have a valid imap url which points off to bogus folders (whatever the structure of the relative link was) and we get all confused and end up crashing. To fix this for images with relative links, we had to make sure the BASE tag was being honored for URL resolution and that fixed the crash. cc'ing Marc our resident style system expert... It looks like when we resolve the relative sytle sheet urls, we aren't using the BASE tag our mime emitter generates. Do you know where we should start poking to look at this? I'll attach a stack crawl showing where in the code imap is getting told to incorrectly resolve the relative link. To see the HTML we are emitting, one can turn on a MIME log by setting your log module to MIME:5. I wonder if the style rules get generated before the BASE tag is being parsed? Probably not...but I thought I'd mention it.

Here's the stack crawl showing how we get called to resolve a relative link, bypassing the BASE tag.... nsMsgMailNewsUrl::Resolve(nsMsgMailNewsUrl * const 0x047403a4, const char * 0x0012dfb4, char * * 0x0012e0e4) line 516 NS_MakeAbsoluteURIWithCharset(char * * 0x0012e0e4, const nsString & {...}, nsIDocument * 0x04754058, nsIURI * 0x047403a4, nsIIOService * 0x00d11c60, nsICharsetConverterManager * 0x00d2ad10) line 155 + 26 bytes nsHTMLAnchorElement::GetHrefCString(nsHTMLAnchorElement * const 0x047c555c, char * & 0x00000000) line 689 + 49 bytes nsStyleUtil::IsHTMLLink(nsIContent * 0x047c5528, nsIAtom * 0x00d987f0, nsIPresContext * 0x03ceb420, nsLinkState * 0x0012e188) line 519 SelectorMatchesData::SelectorMatchesData(nsIPresContext * 0x03ceb420, nsIContent * 0x047c5528, nsISupportsArray * 0x047cf368, nsCompatibility * 0x00000000) line 2815 + 29 bytes ContentEnumData::ContentEnumData(nsIPresContext * 0x03ceb420, nsIContent * 0x047c5528, nsISupportsArray * 0x047cf368) line 3272 + 29 bytes CSSRuleProcessor::RulesMatching(CSSRuleProcessor * const 0x04734a50, nsIPresContext * 0x03ceb420, nsIAtom * 0x00da4420, nsIContent * 0x047c5528, nsIStyleContext * 0x04743e28, nsISupportsArray * 0x047cf368) line 3435 EnumRulesMatching(nsISupports * 0x04734a50, void * 0x0012e26c) line 841 nsSupportsArray::EnumerateForwards(nsSupportsArray * const 0x047346e8, int (nsISupports *, void *)* 0x02299f20 EnumRulesMatching(nsISupports *, void *), void * 0x0012e26c) line 357 + 20 bytes StyleSetImpl::WalkRuleProcessors(int (nsISupports *, void *)* 0x02299f20 EnumRulesMatching(nsISupports *, void *), void * 0x0012e26c, nsIContent * 0x047c5528) line 2282 StyleSetImpl::ResolveStyleFor(nsIPresContext * 0x03ceb420, nsIContent * 0x047c5528, nsIStyleContext * 0x04743e28, int 0) line 943 nsPresContext::ResolveStyleContextFor(nsPresContext * const 0x03ceb420, nsIContent * 0x047c5528, nsIStyleContext * 0x04743e28, int 0, nsIStyleContext * * 0x0012e334) line 697 + 38 bytes nsCSSFrameConstructor::ResolveStyleContext(nsIPresContext * 0x03ceb420, nsIFrame * 0x04722750, nsIContent * 0x047c5528, nsIAtom * 0x00d987f0, nsIStyleContext * * 0x0012e334) line 6795 + 31 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x04015c70, nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent * 0x047c5528, nsIFrame * 0x04722750, nsFrameItems & {...}) line 7150 + 53 bytes nsCSSFrameConstructor::ProcessBlockChildren(nsIPresShell * 0x04015c70, nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent * 0x047c4a90, nsIFrame * 0x04722750, int 1, nsFrameItems & {...}, int 1) line 12465 + 37 bytes nsCSSFrameConstructor::ConstructBlock(nsIPresShell * 0x04015c70, nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x047cd8b4, nsIContent * 0x047c4a90, nsIFrame * 0x04722678, nsIStyleContext * 0x04743e28, nsIFrame * 0x04722750) line 12414 + 36 bytes nsCSSFrameConstructor::ConstructFrameByDisplayType(nsIPresShell * 0x04015c70, nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x047cd8b4, nsIContent * 0x047c4a90, nsIFrame * 0x04722678, nsIStyleContext * 0x04743e28, nsFrameItems & {...}) line 6511 + 43 bytes nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x04015c70, nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent * 0x047c4a90, nsIFrame * 0x04722678, nsIAtom * 0x00d9b5f8, int 3, nsIStyleContext * 0x04743e28, nsFrameItems & {...}, int 0) line 7298 + 48 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x04015c70, nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent * 0x047c4a90, nsIFrame * 0x04722678, nsFrameItems & {...}) line 7165 + 56 bytes nsCSSFrameConstructor::ProcessBlockChildren(nsIPresShell * 0x04015c70, nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent * 0x046ac118, nsIFrame * 0x04722678, int 1, nsFrameItems & {...}, int 1) line 12465 + 37 bytes nsCSSFrameConstructor::ConstructBlock(nsIPresShell * 0x04015c70, nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x047cd57c, nsIContent * 0x046ac118, nsIFrame * 0x047225f0, nsIStyleContext * 0x04865f60, nsIFrame * 0x04722678) line 12414 + 36 bytes nsCSSFrameConstructor::ConstructFrameByDisplayType(nsIPresShell * 0x04015c70, nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, const nsStyleDisplay * 0x047cd57c, nsIContent * 0x046ac118, nsIFrame * 0x047225f0, nsIStyleContext * 0x04865f60, nsFrameItems & {...}) line 6511 + 43 bytes nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x04015c70, nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent * 0x046ac118, nsIFrame * 0x047225f0, nsIAtom * 0x00d994b0, int 3, nsIStyleContext * 0x04865f60, nsFrameItems & {...}, int 0) line 7298 + 48 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x04015c70, nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent * 0x046ac118, nsIFrame * 0x047225f0, nsFrameItems & {...}) line 7165 + 56 bytes nsCSSFrameConstructor::ProcessChildren(nsIPresShell * 0x04015c70, nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent * 0x047589f8, nsIFrame * 0x047225f0, int 1, nsFrameItems & {...}, int 1, nsTableCreator * 0x00000000) line 11307 + 43 bytes nsCSSFrameConstructor::ConstructDocElementFrame(nsIPresShell * 0x04015c70, nsIPresContext * 0x03ceb420, nsFrameConstructorState & {...}, nsIContent * 0x047589f8, nsIFrame * 0x047218ac, nsIStyleContext * 0x047a4db0, nsIFrame * & 0x047225f0) line 3549 nsCSSFrameConstructor::ReconstructDocElementHierarchy(nsCSSFrameConstructor * const 0x0466d798, nsIPresContext * 0x03ceb420) line 7363 + 63 bytes StyleSetImpl::ReconstructDocElementHierarchy(StyleSetImpl * const 0x046b7b18, nsIPresContext * 0x03ceb420) line 1233 PresShell::ReconstructFrames() line 4899 + 38 bytes PresShell::StyleSheetAdded(PresShell * const 0x04015c78, nsIDocument * 0x04754058, nsIStyleSheet * 0x047cc590) line 4911 nsDocument::InsertStyleSheetAt(nsDocument * const 0x04754058, nsIStyleSheet * 0x047cc590, int 1, int 1) line 1293 CSSLoaderImpl::InsertSheetInDoc(nsICSSStyleSheet * 0x047cc590, int 2, nsIContent * 0x047cecb8, int 1, nsICSSLoaderObserver * 0x047584a4) line 1103 CSSLoaderImpl::SheetComplete(nsICSSStyleSheet * 0x047cc590, SheetLoadData * 0x047cef18) line 813 CSSLoaderImpl::ParseSheet(nsIUnicharInputStream * 0x047ceec0, SheetLoadData * 0x047cef18, int & 1, nsICSSStyleSheet * & 0x047cc590) line 868 CSSLoaderImpl::LoadInlineStyle(CSSLoaderImpl * const 0x04758620, nsIContent * 0x047cecb8, nsIUnicharInputStream * 0x047ceec0, const nsString & {...}, const nsString & {...}, int -1, int 2, nsIParser * 0x047567a0, int & 1, nsICSSLoaderObserver * 0x047584a4) line 1287 + 24 bytes

I checked this out and the base HREF is not the problem. I created a testcase that uses the base HREF and links a stylesheet using the relative URL, it works fine. The problem only happens when I follow the HTML in the MIME log and put the HEAD inside of the BODY, then it is apparently ignored. I'll attach first the working testcase, then the same testcase with the HEAD inside of the BODY showing that it does not work. If we want to handle this kind of markup we will probably have to get some work from the parser folks.

The structure of the markup shown in the MIME log is really bad. I remember seeing thsi sort of problem before and IIRC we decided that libmime was not able to make any better markup so we had to shelve the bug. I wish I could solve thsi in style, but the BASE HREF is never even getting to the CSSLoader...

yes the html the mime generator (which dates back to netscape 2.0??) is pretty nasty. So if the BASE tag were somehow inside the HEAD tag instead of coming after the HEAD tag, the style system will then start honoring the base tag? I'll take a look to see if I can make mime do that. Although I think we've looked at that before and it wasn't feasible at the time since we emit the head tag before we even start converting the body........thanks Marc.

Marc, one of your comments confused me a bit. You said: "HEAD is enclosed by BODY (as showin in the MIME trace) and is apparently ignored" When I look at the mime log, i'm seeing the head tag, then the body tag and the base is inside the body. I'm not seeing the head enclosed by the body. did I misread what you wrote?

Oops - I was not clear. What I'm seeing is as follows: The base HREF is in the first BODY, then another HTML and BODY are opened, then another HEAD (after the BODY that follows the <!-- C-WRAP MODS --> comment), and then the LINK is found. Here is some markup that tries to mimic what I see: <html> <body> <BASE HREF="http://cbs.marketwatch.com/news/default.asp?siteid=mktw"> <html><body><head> <link rel=stylesheet type="text/css" href="/styles/css/global.asp"> </head> <p class="t23">test: class t23 has color=#ff0000 </body> </html> So, the HEAD is in the BODY, but that is just for the LINK. The BASE HREF is in the first BODY. If I pull the BASE HREF out of the BODY and either put it into the head OR just leave it hanging then it seems to apply. For example, this modification of the previous markup works: <BASE HREF="http://cbs.marketwatch.com/news/default.asp?siteid=mktw"> <html><body><head> <link rel=stylesheet type="text/css" href="/styles/css/global.asp"> </head> <p class="t23">test: class t23 has color=#ff0000 </body> </html> I hope that is less unclear, and possibly even helpful!

This is a topcrash for M09, added topcrash keyword Added M09 crash [@ nsStreamConverter::Init ] to Summary for tracking. Here is a recent stack trace: nsStreamConverter::Init [d:\builds\seamonkey\mozilla\mailnews\mime\src\nsStreamConverter.cpp line 550] nsStreamConverter::AsyncConvertData [d:\builds\seamonkey\mozilla\mailnews\mime\src\nsStreamConverter.cpp line 1075] nsStreamConverterService::AsyncConvertData [d:\builds\seamonkey\mozilla\netwerk\streamconv\src\nsStreamConverterService.cpp line 639] nsDocumentOpenInfo::RetargetOutput [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp line 444] nsDocumentOpenInfo::DispatchContent [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp line 397] nsDocumentOpenInfo::OnStartRequest [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp line 242] nsStreamListenerTee::OnStartRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerTee.cpp line 14] nsOnStartRequestEvent0::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp line 212] nsStreamListenerEvent0::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp line 107] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 589] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 522] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 1070] KERNEL32.DLL + 0x248f7 (0xbff848f7) 0x00688b5a Here are some comments from recent crashes: (29679498) Comments: crash when browsing (29676687) Comments: Crash when loading a mail message with a linked page. (29668792) Comments: select a message IMAP (29668596) Comments: Opened message from search results (sent folder)

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

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

So this turns out to be a little harder than I thought it would be. =). First of all a message could have multiple inline parts (i.e. I can send multiple web pages in the same message). This means you could run into multiple BASE tags, 1 for each inlined part. I thought I would make the bad HTML mime emits a little worse by wrapping each inline part with it's own HTML & BODY tags. That way I could have the base tag for that part stand outside of the BODY for that part. Something like this: <html> // for the inline part <BASE HREF="http://cbs.marketwatch.com/news/default.asp?siteid=mktw"> <body> // for the inline part // now the RAW html for the web page which has it's own html, body and head tags... <html> <body> <head> <link rel=stylesheet type="text/css" href="/styles/css/global.asp"> </head> </body> </html> // now close out our inlined part </body> </html> Unfortunately that didn't have the effect I was hoping for. We still don't find the BASE url when resoloving the link. My knowledge of HTML isn't could enough to even know if my approach is valid or not.

does anyone know if there's an HTML tag you can use to enforce a "scoping" policy with regards to the BASE tag? i.e I really want to do something like: <some tag> <BASE ....> <html><body> .... </body></html> // random raw html for the inlined web page </some tag> followed by the same wrapper around the next inline web page in the message: <some tag> <BASE ....> <html><body> .... </body></html> // random raw html for the inlined web page </some tag>

mscott, there is nothing I am aware of that does what you want. BASE is technically limited to the HEAD, I think, so even supporting it in the body is a quirkiness we have chosen to support (or support by accident). Given that, we could always create a proprietary scoping tag... I had another idea, in fact I think I've mentioned it before: why not make the mail message wrap the individual 'inline' web pages in IFRAMEs? That way, they would each be completly scoped. This way the markup could actually be valid too, since I believe that we are taking advantage of some very quirky behaviors that allow multiple heads, multiple html and body elements in the same document. Just a thought...

that's a very interesting idea Marc. It certainly would clean up all the nested html/head/body tags that we wrap around each inlined part in the message. One problem that jumps out at me is that then each inline part scrolls separately from the message body. Or is it possible to have several iframes scroll together? I didn't think you could do that but maybe I'm wrong.

I think that each IFRAME would have to be the full size of the webpage so that the IFRAME does not have its own scrollbar. I'm not sure how to do that part... It might be possible to specify an automatic height on an IFRAME, but I couldn;t figure it out. Maybe we could put some support into layout for automatic IFRAME height to enable this. Width would just be 100% I think.

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

I got a prototype of this working yesterday where I convert each inline HTML part into an iframe with another imap url to fetch the part. i.e. <iframe scrolling="no" height="100%" width="100%" src="imap://.....&part=1.2> I think this is an interesting avenue to take. 1) It cleans up some of the ugly HTML libmime generates because we no longer end up nesting a bunch of html and body tags for each inline part. 2) It's going to make mstoltz happy from a security point of view. (More on that later) However the big draw back I see right now is that layout currentl does not allow you to have multiple iframes scroll together. We have the intial iframe that has the message body and a scroll bar. Inside of that iframe we now have iframes for each inlined html part. We don't want vertical scrollbars for each of these nested iframes. We want them to take up 100% and then rely on scrolling from the parent frame. My gut tells me this is going to be a hard requirement for the layout guys to implement if we go down this path. But I don't want to speak for them =). Maybe Marc wants to speak for them =).

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

I'm not sure what it will take to make an iframe 'shrink-wrap' around the page it contains - I'll start investigating and report back what I find.

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

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

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

Note to qa contact, please test all the url's for the dup bugs when this is fixed and being verified.

Marc, any luck?

No luck yet. To be honest, I've been swamped with other issues and have not put a lot of effort into this. Is it critical? Shall we open a bug on me to put it on my 0.9.1 radar?

My main concern is that there are already 8 dups of this which means it's not too uncommon to get into this situation, and it's pretty bad to crash when reading a message. If it's possible to come up with a solution for 0.9.1 it would be appreciated.

I opened bug 80713 on the IFRAME height idea.

maybe I missed the point here but how comes it was working before? Do we really need to go the iFrame way or should we just try to fix the regression?

Fixing the regression and improving the nasty markup from libmime are somewhat orthogonal, I think. We can probably fix the crash, but I'm not sure we can honor multiple misplaced <BASE> tags correctly...

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

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

I like JF's question: what's the simplest thing we can do to get the crash off the radar right now? If we need a more elegant solution, we can file another bug to cover that for m.9.2.

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

Couple comments: 1) After spending the weekend and today hacking on mime to get this to work, I've come to the conclusion that it just isn't possible. The best I could do was get the base tag working some what iff the very first multi-mixed part in the message contained the content-location header. Then and only then could I come close to emitting the base tag as part of the first <header> tag we issue when we begin to display a message. Otherwise, we always have to emit parts of the message body we've already parsed (i.e. other parts) before we discover the content location header in a subsequent part. I'm convinced that base tag urls could not have worked under the current libmime architecture unless the parser used to be able to discover the base tag when it was nested. The only way to make this work would be to introduce another pass in libmime where we first parse all the message parts scanning for a content-location header then begin generating the html for the body and re-parsing the parts for display. Obviously that's just not going to perform right. I think the right idea is to go down the iframe for each part approach which is a more long term solution. 2) So here's a hokey work around for .9.1. Don't allow resolution against mailnews urls. We used to have this policy in place in NS6 but we took it out in order to allow messages to use anchor tags (think status reports =)). This patch, still allows anchors to get resolved against the mailnews url. So that feature won't break. Everything else won't get resolved against mailnews urls though. One catch: this will cause something to break I just don't know what. I remember writing in a bug a year or so ago "gee, you are really lucky I just enabled url resolution for nsMsgMailNewsUrl to make anchors work. This is going to make this bug work too...". I just don't know what bug that was.

Can we not DOM-insert the <BASE HREF> tag when you see the Content-Base: or Content-Location: header? I guess I don't understand why we need the multiple passes, but it is clear to me that there are a _lot_ of things about MIME HTML generation that I don't understand. As far as having the <iframe>s scroll as a unit, I'm a little surprised that it's not possible. Lots of sites have ads in <iframe>s, and they scroll with the rest of the page, no? Adding dbaron for possible CSS trickery.

> As far as having the <iframe>s scroll as a unit, I'm a little surprised that > it's not possible. Lots of sites have ads in <iframe>s, and they scroll with > the rest of the page, no? I think what mscott meant was having the inner IFRAMEs shrink to the "intrinsic height" of the document so that the inner IFRAMEs don't need scrollbars (but only the outer ones do). While such rendering seems quite unnatural for IFRAMEs it seems like the natural thing to do for OBJECTs containing text/html without any specified height/width. However, that doesn't mean it wouldn't be hard to implement. See http://www.w3.org/TR/html4/struct/objects.html#embedded-documents

thanks for that link David. Yeah, something like the object tag is definetly what we are looking for here.

FWIW, the RFE for implementing OBJECT for text/plain and text/html content has been around for years and not much progress has been made, although there were some recent suggestions of just making it work like an IFRAME. See bug 678.

Okay the work around has been checked in. I'm marking this bug fixed. QA: there's a long list of bugs marked dups of this one that have different urls which need tested. You'll have to back track through the links to find all the urls that need tested. I just went through the first 5 or so and made sure they all worked. Remaining work for implementing an iframe or object tag for each inlined part has been filed as a new Bug: 82280. Please cc yourself to that bug if you wish track this further.

FYI..I'm starting the verification on this now, it will take a little while to get through all the links.

Using build 2001-05-23 on win, mac and linux I did a Send Page on all of the web pages in all the duplicate bugs and this one to myself. I retrieved the msgs and had no crashes. I will verify this. If we start seeing other pages crash when viewing them in a mail message we should start a new bug and reference this one for possible helpful information on testing for regression.