If you go to: http://gemal.dk/ and do a File -> Send Page and read the mail with Mozilla the backgroud image doesn't show. It's properly because of the local reference BACKGROUND="pics/bg.gif" in the attached webpage. In Netscape 4.x it shows correctly. Shouldn't it also be the case in Mozilla. Build 2000052208

sound mime-ish to me....not sure if there's anything we can do here....post beta2 that's for sure...

This must be an easy one to fix, since all the other images on the attached webpage are shown.

Ok, the problem here is that layout is not responding to BASE tags for BACKGROUND images (and JavaScript by the way) like it does for "IMAGE SRC=" tags. I will attach a distilled HTML file (yes...the HTML is ugly...I know) but the issue is that the "IMAGE SRC" tags will use the BASE root URI, but the BACKGROUND tag will not. Looks like the parser treats these tags differently in this case. Will reassign to the Browser/layout people. - rhp

This is really a layout/parser issue.

One more time.

Mark, could you have a look at this, if not give it to me and I'll investigate further, thanks!

Firstly, I'm sure the <base HREF> tag is applying to background images as well as <IMG> images: I created a testcase that has a relative-URL background and a <BASE HREF> - I see the background image. If I move the <BASE HREF> tag to AFTER the body definition (illegal actually, it has to be in the head), then it will not apply to the body's background, so it appears that the BASE href is only applied to elements that appear after it. The HTML4.01 spec says: "When present, the BASE element must appear in the HEAD section of an HTML document, before any element that refers to an external source. The path information specified by the BASE element only affects URIs in the document where the element appears." (section 12.4, http://www.w3.org/TR/html401/struct/links.html#edef-BASE) I do not know how the BASE is being inserted into the document in the mail window, it obviously is or none of the images would show up. However it is being done it needs to change so that it conforms to the HTML 4.01 spec., i.e. put it in the HEAD element before any LINK's or other possible external references. I'm assigning this to mscott since he is listed as the Module Owner for MailNews and I could not figure out a more specific candidate to send it to.

rhp was just talking about this the other day. Thanks for the detecive work Mark. over to rhp

Yes, I know this. I am told about the evil of HTML coming out of libmime about every month or so. The problem is that we are not in control of all the HTML being created here. In fact, we are in control of small amounts of it. The fact that MHTML can encapsulate ANY html document means that we wrap entire HTML documents (some of the time) and plain text on other occassions. Take the case where we are encapsulating an MHTML message. The core of the body will be an external HTML document with its own HTML, HEAD, BODY, etc...tags and we still need to encapsulate that in other HTML to do add things like "So and so wrote: ", indentation, etc... With this case, we have two choices. Choice 1: Do preprocessing in libmime and make sure the output is totally valid HTML What does this mean? It means that we are parsing the HTML in libmime. Then with all the pieces, rebuild some sort of document that is "pretty" HTML. With that approach, we now have libmime parsing the HTML to create HTML and then pass that to layout where it will be parsed again. Parsing the data twice. (The alternative is having libmime parse it into some sort of DOM/XIF representation. That would equate to a rewrite of libmime) Choice 2: Output something that our parser can grok and let the people who know how to write HTML parsers handle it. This is what we do today and have done since 2.0. Ugly, YES, but it works and has worked for years. Background images work just fine if you feed the attached HTML into 4.x. Let's look at and example case for why I don't choose "Choice 1". Take into account the case where someone sends you an HTML message with 2 HTML attachments in a MIME multipart message format. Now you have to parse THREE HTML documents, try to come up with a single HTML document that makes sense and pass that along to layout. The variations on this theme are endless. I'll gladly sit and discuss this situation with anyone, but unless someone wants to take over libmime and rewrite it from scratch, I think we will be left with the lesser of two evils which is where we are today. - rhp

rhp: I think I understand your situation, but I do not understand why this is now my bug. If we are not going to fix the code then let's just mark it wontfix instead of bouncing it between engineers. If we need to live with the lesser of two evils as you stated then lets admit that and close this bug. Please advise. As an after thought: have we considered using frames or Iframes to wrap the HTML?

Denied approval for nsbeta3. This is a problem in libmime, and it has been made clear that libmime cannot fix it. This is also being Future'd since it will not be in the release if it cannot get into beta3. Of course, it is still open for Mozilla party memebers to look into and hopefully propose solutions for.

Marking WONTFIX: problem with markup won't be fixed by libmime (see comments rhp@netscape.com 2000-07-28 13:22)

Reading the mail in todays build gives me really weird message: 284[120844d8]: fep2.sprawl.dk:A:SendData: 2 select "pics/bg.gif" 284[120844d8]: fep2.sprawl.dk:A:CreateNewLineFromSocket: 2 NO The specified mailbox does not exist

Henrik, this might be worth reporting as a regression rather than in this closed bug. Tat said, I'm not seeing it...