Background image not shown in "Send Page" mail

RESOLVED WONTFIX

Status

()

Core
Layout
P3
normal
RESOLVED WONTFIX
18 years ago
17 years ago

People

(Reporter: Henrik Gemal, Assigned: Marc Attinasi)

Tracking

Trunk
Future
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-])

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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

Comment 1

18 years ago
sound mime-ish to me....not sure if there's anything we can do here....post
beta2 that's for sure...
Assignee: mscott → rhp
Component: Mail Back End → MIME
Target Milestone: --- → M19
(Reporter)

Comment 2

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

Updated

18 years ago
Status: NEW → ASSIGNED

Updated

18 years ago
Keywords: correctness, nsbeta3

Comment 3

18 years ago
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

Comment 4

18 years ago
Created attachment 11986 [details]
The attached HTML will show the problem pretty easily

Comment 5

18 years ago
This is really a layout/parser issue.
Status: ASSIGNED → NEW

Comment 6

18 years ago
One more time.
Assignee: rhp → clayton
Component: MIME → Layout
Product: MailNews → Browser
QA Contact: lchiang → petersen
Mark, could you have a look at this, if not give it to me and I'll investigate
further, thanks!
Assignee: clayton → attinasi
(Assignee)

Comment 8

18 years ago
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.
Assignee: attinasi → mscott
Component: Layout → Mail Window Front End
OS: Windows 2000 → All
Product: Browser → MailNews
Target Milestone: M19 → ---
(Assignee)

Comment 9

18 years ago
Created attachment 12017 [details]
TESTCASE showing relative URL in background does work if BASE HREF is in the correct place.

Comment 10

18 years ago
rhp was just talking about this the other day. Thanks for the detecive work Mark.

over to rhp
Assignee: mscott → rhp
Component: Mail Window Front End → MIME

Comment 11

18 years ago
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
Assignee: rhp → attinasi
Component: MIME → Layout
Product: MailNews → Browser
(Assignee)

Comment 12

18 years ago
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?

(Assignee)

Comment 13

18 years ago
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.
Status: NEW → ASSIGNED
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
(Assignee)

Comment 14

17 years ago
Marking WONTFIX: problem with markup won't be fixed by libmime (see 
comments rhp@netscape.com 2000-07-28 13:22)
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 15

17 years ago
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
(Assignee)

Comment 16

17 years ago
Henrik, this might be worth reporting as a regression rather than in this closed
bug. Tat said, I'm not seeing it...
You need to log in before you can comment on or make changes to this bug.