21682 - [DOGFOOD] BASE tag ignored when Inserting HTML into Editor

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P3)

Description

[Katsuhiko Momoi]

** Observed with all 3 12/13/99 Win32 builds **
** This was noticed by marina for Latin 1 messages w/ attachments.
    It is also observed for Japenese msgs with attachments. **


When replying under HTML send-option to a message which includes an
HTML attachment, an error occurs and the mail cannot be sent.
This used to be OK quite recently and so this seems like a
regression.

Here's hwo you can reproduce this bug:

1. Send yourself a web page, e.g. the above URL, using Mozilla or 4.7x.
2. Receive this with Mozilla Messenger and display the attachment
   inline.
3. Now engage "Reply" on this message. Whe the quoting is completed,
   try to send the message with or without adding text.
   This is when you get an error, "[String ID(hex)=80004005?]",
   and the message refueses to go out.

Apparently there is no way to reply to this type of messages
with the current builds. It does not seem to matter what
the contebt of teh attachment is. This problem also does not
happen when you are simply attaching a web page to a message
-- it happens only when you reply to a msg with an attachment.


3.

Comment 1

[leger]

Putting on PDT+ radar.  We think this may be a dup though.

Please check out today's build...may be fixed.

Comment 2

[Katsuhiko Momoi]

** Re-checked with 12/14/99 Win32 build (1999121408) **

This problem is still occurring with the above build.

This problem started happening yesterday, I believe.
Lisa, is there a duplicate somewhere>

Comment 3

[Jean-Francois Ducarroz]

Reassign to rhp.

Rich, when we parse the body for images in nsMsgComposeAndSend::ProcessMultipartRelated, the call image->
GetSrc(tUrl) failed and return NS_ERROR_NOT_IMPLEMENTED. Then, later, this error is changed to
NS_ERROR_FAILURE (0x80004005).

Comment 4

[lchiang]

kat - I can't find the duplicate right now.

Comment 5

[rhp (gone)]

Ok, here's the deal. I belive this boils down to a problem inserting HTML with
HREF tags into the editor. When we display a web page that has been sent from a
remote system, the HREF tag is written to layout so a line like:

         <img SRC="Logo.gif" BORDER=0 height=211 width=461></td>

will build the proper URL by appending Logo.gif to the BASE URL.

This seems to be broken now.

- rhp

Comment 6

[rhp (gone)]

I belive this boils down to a problem inserting HTML with a BASE tag into the
editor. In the message compose window, I am trying to insert some HTML that
looks like:

<BASE HREF="http://www.foo.com/">
.
.
.
         <img SRC="Logo.gif" BORDER=0 height=211 width=461></td>

The editor/layout should build Logo.gif into http://www.foo.com/Logo.gif, but
we are asserting when trying to build this URL . Note: this message displays
fine with the same approach, its just inserting that is a problem.

This is where we assert:

nsDebug::Assertion(const char * 0x014c9140, const char * 0x014c9134, const char
* 0x014c9108, int 231) line 186 + 13 bytes
nsSimpleURI::Resolve(nsSimpleURI * const 0x03696840, const char * 0x036a7a80,
char * * 0x0012e814) line 231 + 35 bytes
NS_MakeAbsoluteURI(const char * 0x036a7a80, nsIURI * 0x03696840, char * *
0x0012e814) line 143 + 20 bytes
NS_MakeAbsoluteURI(const nsString & {"Logo.gif"}, nsIURI * 0x03696840, nsString
& {""}) line 154 + 17 bytes
nsHTMLImageLoader::SetURL(const nsString & {"Logo.gif"}) line 87 + 25 bytes

The asserts happen after this call:

    return baseURI->Resolve(spec, result);

where baseURI is "about:blank" which is the document we start the editor with,
but we need to use the information in the BASE= tag.

- rhp

Comment 7

[rhp (gone)]

Attachment: HTML I'm trying to insert

Comment 8

[Akkana Peck]

I created a much simpler test page, and have updated the URL.

In this test, src="deathvalley/danteT.jpg" is the url passed to InsertHTML, and
src="deathvalley/danteT.jpg" is what comes through.

Rich thinks that InsertHTML should be rewriting the URL according to the BASE of
the document, and says it used to do that.  InsertHTML doesn't do any inserting
directly -- it just calls CreateContextualFragment.  And nothing has changed
recently in the InsertHTML code.  So this must be an issue with
CreateContextualFragment.

Passing this on to Rick, and he and Rich can debate whether
CreateContextualFragment should be rewriting according to the BASE or not.
(Personally, I would have guessed that was libmime's job since we wouldn't want
InsertHTML rewriting URLs in the html editor when someone is editing a web page
that happens to have a BASE in it.)

Comment 9

[Akkana Peck]

Upon further discussion with Rich, I realize that it isn't that he thinks the
inserted html is being inserted wrong; it's that the inserted html is correct,
but when it's displayed as a reply in the mail compose window, the base url
isn't being respected, so the relative url, which was correctly inserted into
the message, is shown as a missing image, and later when the message is sent,
there's an error.

The base url is in the body, not the head, since that's where it was inserted.
Perhaps there was a change recently to layout to stop respecting base tags in
the body?  Rich says this changed in the last few days.  Adding troy to cc since
this seems like a layout problem (though I don't have a clue what code path is
being followed on send, whether that goes through layout or not.  The error
dialog certainly isn't very helpful).

Comment 10

[rickg]

Rich -- can you provide a snapshot of the content model produced by this page?
I'm wondering whether the <base> is being moved into the head or not.
(I'm asking you to do it because I have 2 PDT+ bugs already and I'm running out
of time.)

Comment 11

[Akkana Peck]

The base is definitely in the body once the document is loaded in the html
compose window.  (Debug->Dump Content Tree or Debug->OutputHTML.)

Comment 12

[rhp (gone)]

Attachment: The HTML debug dump of the compose window

Comment 13

[rhp (gone)]

Hi Rick,
I attached the HTML debug dump that shows the BASE tag in the header.

- rhp

Comment 14

[rickg]

Thanks Rich -- I'll look. One thing though, I really don't believe this is a
PDT+ bug due to likeliness of it's occuring. Removing in order to cause PDT+ to
come to it's senses.

Comment 15

[rhp (gone)]

Sorry Rick, but this happens with EVERY email message that contains an included
web page, image link, etc. Reply/forward is broken on all of these messages. It
is happening to me very often.

We really need this one fixed.

- rhp

Comment 16

[rickg]

There's nothing I can do. The insertfragment code assumes you're inserting
content at the given context (via the dom). The base tag should go into the
head, which is a different context altogether.

It's possible to rearchitect some of this, but the folks we need are not all
here. It's not likely that we'll address this before January.

Comment 17

[rickg]

Resetting target milestone.

Comment 18

[rickg]

So it's january, and as promised I'm looking into this problem. Progress so far
is that I've now proven that the parser is behaving correctly. It seems the
problem is that the nsHTMLFragmentContentSink that receives the parser output is
not doing the right thing with head elements that are found in the body. (So for
example, pasting <title>title</title> also fails).

Vidur: I suggest that we teach the fragment sink to store head elements in a
seperate list, and that you retrieve both fragments when this call returns.
Let's talk some more tomorrow.

Comment 19

[vidur (gone)]

Fixed on 1/6/2000. The HTMLFragmentContentSink now processes BASE elements.

Comment 20

[rhp (gone)]

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

Comment 21

[Katsuhiko Momoi]

Lisa, I decided to keep track of this bug since it seems to be related to
other bugs we are concerned about.

As of 1/11/00 Win32 build, the problem as I reported originally no longer occurs and
we are able to send out "reply" mail to the test msg used for the original bug.
Marking this fix verified.