29653 - Add cite attribute to blockquote

Status: RESOLVED FIXED

(MailNews Core :: MIME, enhancement, P3)

Description

[Ben Bucksch (:BenB)]

HTML 4.0 specifies, that the source of a quote can be inserted as cite
attribute. <http://www.w3.org/TR/REC-html40/struct/text.html#h-9.2.2>

We could use that to show exactly, which quote comes from which msg, if we add
e.g. "cite="news://[e-mail]"" to the blockquote tag (dunno,
which scheme to use for mail). This would be similar to the "References" header,
but with much finer granularity. With this information, we could implement a
context menu item for the quote, which opens the original msg for exactly that
quote.

Comment 1

[rhp (gone)]

I have this working in my tree. I will check it in when we get the M15 
train-a-rolling.

- rhp

Comment 2

[Ben Bucksch (:BenB)]

rhp the bugripper :-)

A question: Which scheme (the part before the first ":" in the URI) did you use
for mail? I don't know of any scheme for a generic msg (i.e. without protocol
and hostname), but maybe I missed one.
IMO, you shouldn't include the hostname for security reasons, but just use the
msg-ID, like in "References".

Comment 3

[rhp (gone)]

What I've currently done for both mail and news is use the Message-ID: header 
that we use for threading and other referencing information in mail/news. Maybe 
I should send you a diff and you can play around with it and see what you 
think.

- rhp

Comment 4

[Ben Bucksch (:BenB)]

Yes, that would be nice. I'll take a look, if I can use the "news:" scheme for
news msgs.

Comment 5

[Ben Bucksch (:BenB)]

rhp,
the cite attribute requests a URI, a pure msg-id is none.

> I don't know of any scheme for a generic msg (i.e. without protocol and
> hostname), but maybe I missed one.

I did miss one: "mid:", defined in RFC 2111
<http://www.ics.uci.edu/pub/ietf/uri/rfc2111.txt>.

> I'll take a look, if I can use the "news:" scheme for news msgs.

Well, it is easy to do with |originalMsg->recipientIsNewsgroup| (assuming this
is the right property to ask), but I'm not sure, we should.

For example our mailinglist/newsgroup-mirror at mozilla.org: I get msgs
delivered per email, and I store them locally (on a local IMAP-server to be
precise), which contain a "Newsgroups:" header. I guess, the property mentioned
above would be true in this case. However, my default newsgroup server might not
carry n.p.m.*. Even if it did, I'd like Mozilla to use the copy from my local
msg store instead of opening a connection to my newsgroup server.

It's a hard question, because in other cases (especially other UAs), a "news:"
scheme might be preferable, but I'm tending towards using "mid:" for all msgs.
Tell me, if you have objections.


I'll query alecf for escaping of the msg-ID.

Comment 6

[rhp (gone)]

Well, I just don't see how using your scheme turns into something usefull in 
the Mozilla client. Keep in mind, if we are going to do this, it would be nice 
to have it functional for email messages. mid:/cid: references only let you 
refer to parts in the same message. Not parts of other messges. I would think 
that we want to be able to have some sort of clickable link that would let the 
user select and Mozilla would bring them to the original message that was 
quoted if possible. This would be possible with message ID's.

- rhp

Comment 7

[Ben Bucksch (:BenB)]

> mid:/cid: references only let you refer to parts in the same message. Not
> parts of other messges.

What follows "mid:" *is* the Message-ID, so you can reference other messages
with it.

cid: specifies a Content-ID (for a MIME-part), which is globally unique, i.e.
you can also reference an arbitary MIME-part outside the current msg with cid
*in theory*, but practically, today's msg stores can't handle duch requests.

That's what the Content-ID part of "mid:" is for: you can *optionally* specify a
Content-ID after the Msg-ID and a slash to reference a MIME-part, which also can
be retrieved with today's msg stores.

<blockquote cite="http://www.ics.uci.edu/pub/ietf/uri/rfc2111.txt">
content-id    = url-addr-spec
message-id    = url-addr-spec
url-addr-spec = addr-spec  ; URL encoding of RFC 822 addr-spec
cid-url       = "cid" ":" content-id
mid-url       = "mid" ":" message-id [ "/" content-id ]
</blockquote>

> I would think that we want to be able to have some sort of clickable link that
> would let the user select and Mozilla would bring them to the original message
> that was quoted if possible.

Yes, exactly this was my intention. But "cite" can contain any URI (possibly
inserted by another UA; see above for an example), so if we leave the scheme
out, we would have to special case. If we use a valid URI, we can implement the
"open original" function generic, i.e. it just opens the URI in the cite
attribute. Even if we do special case (because e.g. a mid protocol handler
implementation is too time-consuming), this would be easier with a "mid:" at the
beginning.

Comment 8

[rhp (gone)]

Ben, 
This is turning into something bigger than I can allow time for. You saw the 
change I made...basically, the plumbing is in place to add a string as a cite. 
If you want to continue from where I left off, please do...otherwise, just 
mark the bug help wanted.

- rhp

Comment 9

[Ben Bucksch (:BenB)]

rhp,
you already did most of the work (thanks again), what I propose is only to turn
the msg-id you used into a valid URL. All we have to do for that, is to escape
it and add a "mid:".
I'm already on this. ACCEPTing.

Comment 10

[Ben Bucksch (:BenB)]

Attachment: The diffs rhp sent me

Comment 11

[Akkana Peck]

Joining cc list ... let me know if there are any problems with the editor's
citing!  

Comment 12

[Ben Bucksch (:BenB)]

akk, you mentioned a "W3C mail quoting spec" in another bug. Did you refer to
<http://www.w3.org/TR/1998/NOTE-HTMLThreading-0105>?

Comment 13

[Akkana Peck]

That looks like the spec I remember, though I might have seen an earlier version
of it.  I can't seem to find the URL I'd seen before.

Comment 14

[Ben Bucksch (:BenB)]

Andreas (you might be the better person to ask about URL escaping),
|rv = anIOServiceObject->Escape("mid:foo%bar", ~(short(0)),
getter_Copies(myGetter));| gives me "mid:foo%bar" again. What am I doing wrong?

Comment 15

[Ben Bucksch (:BenB)]

Attachment: Current state of nsMsgCompose.cpp

Comment 16

[Ben Bucksch (:BenB)]

BTW: mask is nsURLEncode is never used.

Comment 17

[Andreas Otte]

ioserv->Escape trys to be smart and detects %ab, which is a valid hexcode. So it 
thinks foo%bar is already escaped and needs no more escaping.

See bug 26003 for a patch that introduces another mask "url_forced" that forces 
an escaping of the string. Hope this gets in sometime.

Usually ioserv->Escape is used to only encode specific parts of an URL not the 
whole URL. 

I will take a look at rfc2111 myself and think about the proper way to escape 
it.

Comment 18

[Ben Bucksch (:BenB)]

Andreas, RFC2111 is nothing unusual, it just states:
"Since addr-spec in a Message-ID or Content-ID might contain characters not 
allowed within a URL; any such character [...] must be hex-encoded using the %hh 
escape mechanism in [URL]."

Comment 19

[thekingpenguin]

What would the cite attribute do exactly?  My guess would be that the text in
the blockquote would be displayed normally, but perhaps in hover and active
colors when appropriate, and clicking would take you to the designated URI.
Please e-mail me if I am incorrect,

Comment 20

[Ben Bucksch (:BenB)]

thekingpenguin,
the attribute by itself does nothing, but we have the ability to implement
support in the read the way you suggest or the way I mentioned earlier (a
context menu item). This would be another bug/feature however.

Comment 21

[Ben Bucksch (:BenB)]

bug 37209 filed about the access of the information.

Comment 22

[Ben Bucksch (:BenB)]

Mostly fixed by rhp long time ago. Generated content needs a scheme and to be
escaped, though. I think, it's OK to move this to M17.

Comment 23

[Ben Bucksch (:BenB)]

Bug 26003 has been resolved, but a new one came up: bug 43509. If a msg-id
contains a slash, the slash and all following chars will be replaced with "%2F"
("/" escaped).

I'll attach the patch nevertheless. Not my problem, if XPCOM still doesn't work.
I suggest to just check the patch in and wait until the problem solves itself
(i.e. bug 43509 is fixed).

Rich, can you review, please?

Comment 24

[Ben Bucksch (:BenB)]

BTW: See <http://www.ics.uci.edu/pub/ietf/uri/rfc2111.txt> for what I do there.

Comment 25

[Ben Bucksch (:BenB)]

Attachment: Fix, version 2

Comment 26

[Ben Bucksch (:BenB)]

Forgot to update (again!). But no merging problems, lukily. Attaching a new
patch nevertheless.

Comment 27

[Ben Bucksch (:BenB)]

Attachment: Fix, version 3

Comment 28

[Ben Bucksch (:BenB)]

Attachment: Fix, version 4

Comment 29

[Ben Bucksch (:BenB)]

I changed the patch after the review during approval, especially the call to
|Escape|, which now also includes escaping of '/'. This shortens my code
slightly and removes the exposure of the XPCOM bug.

The patch also includes the fix for bug 38494 now, as I couldn't remove the
changes from the diff. Just ignore them (all the |author| stuff).

Comment 30

[Ben Bucksch (:BenB)]

Attachment: Fix, version 5. Including fix for bug 38494.

Comment 31

[Ben Bucksch (:BenB)]

Fix checked in (exactly 4 months after the inital patch :) ).

Comment 32

[Ben Bucksch (:BenB)]

Removing dependency on bug 43509: The patch doesn't use the broken function
anymore.