Open Bug 154836 Opened 23 years ago Updated 3 years ago

Image sent embedded is not used for the style sheet. CID: url types doesn't work for CSS

Categories

(MailNews Core :: MIME, defect)

x86
All
defect

Tracking

(Not tracked)

People

(Reporter: amla70, Unassigned)

References

Details

Attachments

(2 files)

If an image is sent inside a message using the cid: schema, it can't be used from the style sheet (HTML message). If the style sheet instead of the cid: uses an url to the image in a server it workd. If the image is referenced using an <img src="cid: "> it works. Related: bug 61815 and bug 131618 The mail was generated using aspemail (www.aspemail.com), tested in Mozilla 2002062604, win98. If according to the proper RFC the cid: should be used only in <img>, then please don't close this bug as I'll turn it into a RFE because outlook displays the message as I expect.
Attached file message
Simple mail showing the problem. The background should be a dark-blue image tiled.
QA Contact: gayatri → trix
Summary: Image sent embedded is not used for the style sheet → Image sent embedded is not used for the style sheet. CID: url types doesn't work for CSS
*** Bug 198017 has been marked as a duplicate of this bug. ***
I've come into this bug also on Linux. OS should be changed to "ALL". As I had previously filled on bug 198017, it may or may not be related to bug 126309.
OS -> All as requested.
OS: Windows 98 → All
Attachment #89571 - Attachment mime type: text/plain → message/rfc822
Hi, I just ran into the same problem (background images defined as cid: in styles) and found that this is a rather old bug. Is there any reason to not allow styles to refer to embedded images? regards Hadmut
Product: MailNews → Core
let's have the CSS guys have a look at this
Component: MailNews: MIME → Layout: Images
(In reply to comment #6) > let's have the CSS guys have a look at this Is there something new over this bug?
It doesn't work when using relative URL resolved through 'Content-Location' headers, too. Still the same URL inside <img src="..."> (or <body background="...">) is resolved o.k. and the image is displayed.
This isn't a core image bug. The URI the core code sees here for that image is "about:blank". That's not surprising, since nsCidProtocolHandler::NewURI just returns about:blank (well, sort of; it screws up the security context for it, actually, but in a too-restrictive way, so it's ok). I seem to recall that there's code somewhere in mail that munges CID URIs in some contexts to point to the part of the message; clearly that code needs to handle CSS or the cid: protocol handler needs to actually be implemented.
Assignee: ducarroz → nobody
Component: Layout: Images → MailNews: MIME
QA Contact: stephend → mime
> I seem to recall that there's code somewhere in mail that munges CID URIs in > some contexts to point to the part of the message; clearly that code needs to > handle CSS or the cid: protocol handler needs to actually be implemented. Yes, using the DOM Inspector I can see URLs inside <body background="..."> and <img src="..."> are changed to something like: mailbox://...&part=1.2 but then observing the style rules: the URLs inside 'url(...)' are not changed.
I think part of the solution was checked in briefly by mscott here: https://bugzilla.mozilla.org/attachment.cgi?id=129765 The libeditor parts of that checkin were rejected by module peers, and I don't think re-visiting there would do any good. However the rendering part could work to fix at least part of this bug: Index: mailnews/mime/src/mimemrel.cpp =================================================================== RCS file: /cvsroot/mozilla/mailnews/mime/src/mimemrel.cpp,v retrieving revision 1.33 diff -u -w -r1.33 mimemrel.cpp --- mailnews/mime/src/mimemrel.cpp 13 Apr 2003 19:45:08 -0000 1.33 +++ mailnews/mime/src/mimemrel.cpp 13 Aug 2003 22:35:09 -0000 @@ -844,17 +844,37 @@ while(buf < ptr) { /* ### mwelch For each word in the value string, see if - the word is a cid: URL. If so, attempt to - substitute the appropriate mailbox part URL in - its place. */ + the word is a cid: URL. If so, attempt to substitute the appropriate mailbox part URL in its place. + + mscott: but that's not good enough. A given word may have a cid url inside of it such as + with style rules for background images: url(cid:....). + + */ ptr2=buf; /* walk from the left end rightward */ while((ptr2<ptr) && (!nsCRT::IsAsciiSpace(*ptr2))) ptr2++; + + // make sure we are not dealing with a case of url(cid:....)..if so, account for the url( and the closing ); at the + // end of the style rule + if ( (ptr2 - buf) > 8 && ( nsCRT::ToLower(buf[0]) == 'u' && nsCRT::ToLower(buf[1]) == 'r' && + nsCRT::ToLower(buf[2]) == 'l' && buf[3] == '(' && + nsCRT::ToLower(buf[4]) =='c' && nsCRT::ToLower(buf[5]) =='i' && + nsCRT::ToLower(buf[6]) =='d' && buf[7]==':')) + { + // write out "url(: + status = real_write(relobj, buf, 4); + buf += 4; + + // adjust the end ptr2 to go back to the close paren + if ( *(ptr2 - 1) == ';' && *(ptr2 - 2) == ')') + ptr2 -= 2; + } + /* Compare the beginning of the word with "cid:". Yuck. */ if (((ptr2 - buf) > 4) && - ((buf[0]=='c' || buf[0]=='C') && - (buf[1]=='i' || buf[1]=='I') && - (buf[2]=='d' || buf[2]=='D') && + ((nsCRT::ToLower(buf[0]) =='c') && + (nsCRT::ToLower(buf[1]) =='i') && + (nsCRT::ToLower(buf[2]) =='d') && buf[3]==':')) { // Make sure it's lowercase, otherwise it won't be found in the hash table .................
True, we could do that. It seems hacky, but doable, and may be worth it as a short-term fix. However it's pretty fragile; for example it looks to me like: body:before { content: " url(cid:.....) "; } would get substituted, which is not desirable. And other cases where URIs are used might get missed. What it seems to me like we should do is to allow things like: imap://user@HOST:993/fetch%3EUID%3E.folder%3E501670?cid=whatever instead of things like imap://user@HOST:993/fetch%3EUID%3E.folder%3E501670?part=1.2&filename=test.gif and the same thing for mailbox://. That way, we could just implement the CID protocol handler and be done with it, no?
Unfortunately, every time I read the libmime code my eyes start to bleed. :(
Product: Core → MailNews Core
(In reply to comment #16) > *** Bug 429817 has been marked as a duplicate of this bug. *** > reopened that cause is not quite the same: -that is about userChrome and ui styles -there I just discovered that in version 3.0a2 (2008072418) I can use no img at all, even with path url or put aside chrome.

What the fuck, 18 years???????

Gmail's web-based UI has the same bug, so you are in good company, but that's no excuse.

Come on, for fuck's sake.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: