Closed Bug 234210 Opened 21 years ago Closed 10 years ago

[mozTXTToHTMLConv] ScanHTML runs over <head> -> "recognizes" links in <style>

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 964024

People

(Reporter: pir-67, Unassigned)

References

Details

User-Agent: Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.6) Gecko/20040113 MultiZilla/1.6.2.1a I wrote this in the source of a mail : #div { background-image:url("http://www.somewhere-on-the-web/image.png"); } When I saved the file, Mozilla Mail 1.6 changed it into this : #div { background-image:url(<a class="moz-txt-link-rfc2396E" href="http://image.png">"http://image.png"</a>); } That seems to be because of the use of an online file whose location begins with "http://". That made Mozilla believe it's a link and so add a <a> tag. That made the "background-image" CSS parametre not work. Reproducible: Always Steps to Reproduce: 1. Use the command "Insert/HTML" to write some HTML code like this example: #div { background-image:url("http://www.somewhere-on-the-web/image.png"); } The location has to point to an online file so that it contain "http://" 2.Save the message using the normal "save" command 3.To view the source of the saved message, use "reply", select all the message text and then use "insert/HTML". All the source of the selected text appear, especially the style definition and you should see this : #div { background-image:url(<a class="moz-txt-link-rfc2396E" href="http://image.png">"http://image.png"</a>); } (Maybe there is an easier way to view the entire message source, a special command just like in outlook express but I don't now it) Expected Results: Mozilla Mail should not transform the string because I hope that you've understood me because I'm French.
I don't observe this bug with the trunk version but with Mozilla 1.6 sorry
Pierre: What exactly are you trying to do with that style? Are you adding an element to the document with id="div" -- because that's what "#div" is selecting for. Mozilla's HTML compose doesn't automatically create a <div>, just a <body>. If you're trying to set the background image for the entire mail, you would use Format|Page Colors and Background If you specify a remote image (http://...) for the background, Mozilla will automatically include that image as part of the mail and change the URL to the local (cid:) reference -- see bug 176416. I am seeing the symptom you describe in 1.7a, and I'm guessing that the <style> tag's content (that is, the style rules) are being handled just like any other tag's content. I suppose this arguably *is* a bug, but not that many people are going to be composing HTML mail that requires style rules.
Thanks for the recognition of this bug Mike I wish that conversion to a CID was the case. I have never been able to get the background-image (url) to convert a local file or a online linked source to a CID format, either as an attachment or a true CID Perhaps this is a specific problem with Thunderbird, but it plays the same in N7.1 Moz 1.4 The only url reference I have been able to get to work is one that references another newsgroup content source. JoeS
Here is an example of data from the compose window <div style="background-color: rgb(220, 220, 102); background-repeat: repeat; background-attachment: scroll; position: absolute; left: 273px; top: 100px; width: 525px; height: 345px; z-index: 1; background-image: url(file:///C:/My%20Download%20Files/bi_helmet.gif);" After the mail is sent, from view source the URL data does not get converted to CID format, and remains pointing to local Data. IE: <div style="background-color: rgb(220, 220, 102); background-repeat: repeat; background-attachment: scroll; position: absolute; left: 273px; top: 100px; width: 525px; height: 345px; z-index: 1; background-image: url(file:///C:/My%20Download%20Files/bi_helmet.gif);" <br> </font> </div>
There is (sadly) no way, that I am aware of, to place an Attribute Selector and its declarations such as suggested by the use of the #div, or any other item, into the head portion. OE is able to include an Embedded Stylesheet; Moz-Mail/Thunderbird cannot. Without the use of a stylesheet, anything of more than simple construction, causes numerous repetitive entries and complexity in creation and is prone to cause errors. The whole intent of css is defeated. "Table of Contents" suggests that an Embedded Stylesheet is possible, but I cannot get this feature to work. This is *bug 1* . The alternative is to use Inline Styles. When composing html mail, I use local images and not remote images (as most folks do), so I will restrict myself to this. In order for local addressing, Moz-Mail requires file:/// as Joe demonstates in Comment #4 and as Mike mentions in Comment #2 all is in order for a background image for body when using either html or css. Regarding Pierre's query in the Description: In order to view the entire message source (only the content within the body) use Ctrl+a, Edit/Select All or Right Click/Select All. In order to view html Attributes and/or css Properties for the body element, you use Format/Page Colors and Background/Advanced Edit/ and selecting the appropriate tab. This is also the place to enter same when composing the Mail. Css Properties are converted to html Attributes by the Mail Client. Although it does work via the css to html conversion, it is not correct. It used to work properly (cannot recall the version where it changed). This is *bug 2* . Inserting a background image into a table or cell with html or css does not work at all. This is *bug 3* . Inserting a background image into a div (using Insert HTML) with html or css does not work at all. This is *bug 4* . There is no way to view/access the head section. I would love to be able to include a background image to the html element. This is *bug 5* . Regarding Mike's Comment #2 "not that many people are going to be composing HTML mail that requires style rules": From where do you get your statistics? You are right on for Moz users, since it is not user friendly, or does not work. As for IE/OE users, it works and people are using it. -- Gus
This is the original mail with which I've found the bug. I wanted to create I personal mail model and have an online background image in my signature (in order not to send the image with the mail every time). I first create the mail in a HTML file. this is the complete source (I've kept the original so it's in french. "bla bla" does not mean anything): <html> <body> <style> div.message { position:relative; border-style:dashed; border-width:1px; background-color:#FFFACC; padding:5px; } div.message h2 { border-style:solid; border-width:1px; width:20em; margin-top:0px; background-color:#CCDDFF; padding-left:5px; } .message p { padding-left:3px; margin-left:20px; margin-right:25px; border-width:1px; border-left-style:solid; } div.sign { position:relative; bottom:-1em; width:6em; background-color:#CCDDFF; border-style:dotted; border-width:1px; font-style:italic; text-align:center; margin-left:100px; margin-bottom:0px; margin-top:10px; background-image:url("http://membres.lycos.fr/thinkdifferentnow/moulin_mini.png"); background-repeat:no-repeat; } </style> <div class="message"> <h2>Titre</h2> <p> Premier paragraphe : bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla </p> <p> deuxieme paragraphe : bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla </p> <div class="sign"> Pierre </div> </div> </body> </html> Then I opened this file in a browser, selected it and used the "copy" command. Afterwards, I pasted it in the mail composition window and at this time the background image was still visible. But after having saved the message, the "background-image" value became this : background-image:url(<a class="moz-txt-link-rfc2396E" href="http://membres.lycos.fr/thinkdifferentnow/moulin_mini.png">"http://membres.lycos.fr/thinkdifferentnow/moulin_mini.png"</a>); This is the source code after saving: <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> <style> div.message { position:relative; border-style:dashed; border-width:1px; background-color:#FFFACC; padding:5px; } div.message h2 { border-style:solid; border-width:1px; width:20em; margin-top:0px; background-color:#CCDDFF; padding-left:5px; } .message p { padding-left:3px; margin-left:20px; margin-right:25px; border-width:1px; border-left-style:solid; } div.sign { position:relative; bottom:-1em; width:6em; background-color:#CCDDFF; border-style:dotted; border-width:1px; font-style:italic; text-align:center; margin-left:100px; margin-bottom:0px; margin-top:10px; background-image:url(<a class="moz-txt-link-rfc2396E" href="http://membres.lycos.fr/thinkdifferentnow/moulin_mini.png">"http://membres.lycos.fr/thinkdifferentnow/moulin_mini.png"</a>); background-repeat:no-repeat; } </style> <div class="message"> <h2>Titre</h2> <p>Premier paragraphe : bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla </p> <p>deuxieme paragraphe : bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla </p> <div class="sign">Pierre </div> </div>
OK, Pierre -- that is some pretty cool CSS for email. So you are only using the remote image as background to the sig. You're completely right about the problem, so I'll confirm this bug. As a workaround, remove the background-image from the <style> and put it inline: <div class="sign" style="background-image:url(http://...);"> I tried this, and it works. By the way, you don't need quotemarks around the uri inside the url() construct; use: url(http://...) instead of url("http://...")
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: url recognition transform a url("") CSS value in a <style> tag → url recognition transforms a url() CSS value inside a <style> tag
Re. Comment #5 I have to add that although it is impossible to place a stylesheet into the head section as it normally should be, it is however, possible to include the stylesheet in the body section, just as Pierre demonstrates in Comment #6. Not that this is proper, but it does work. Gus
CC'ing the author of the URL recognizer, but it might be possible to work around the problem like this: <style> /* <!-- fool the URL recognizer */ #div { background-image:url("http://www.somewhere-on-the-web/image.png"); } /* end fooling the URL recognizer --> */ </style>
How and where exactly did you save the email? From the composer or in the message viewer (after sending/saving as draft)? And, most importantly: under which filename did you save the mail, which extension? .html, .txt, .eml or something else? <a class="moz-txt-link-rfc2396E" is inserted by the txt->html converter. Because the problematic part is supposed to be HTML already, no txt->html conversion is should happen and something outside the converter is going wrong: user error or bad code paths in Mailnews. I agree with the reporter that this is a low priority bug, this is nothing Mailnews tries to support.
> 2.Save the message using the normal "save" command Oh, you mean Save As Draft? Wait, I think I know what's happening: You save the msg as Draft (from HTML Composer). Assuming your mail send format option is not "as plaintext", the msg shoudl get saved as HTML. It think some of the same code path as for sending is used, because the HTML "prettying-up" code (scanHTML()) is running, which recognizes URL *in HTML* typed by the user, but not marked as URL via <a>, i.e. it makes URLs in content clickable. It seems *this* code is messing up your CSS, because it treats the CSS as normal "content". The relevant code is mozTXTToHTMLConv::ScanHTML(). There is a part "if a tag, skip until </a>", we should do the same for <head>, i.e. skip the whole header. (Yes, it's a very primitive HTML parser.) Because <style> is supposed to be in the <head> section, this should fix it. It actually wouldn't fix your example, because it's invalid: Your <style> is inside <body>. If you fix that, it should work. Neil's suggestion should work, too, because the parser knows about HTML comments <!-- / -->. This may be advisable anyways, because you're sending that data out per mail, and you'll find all sorts of HTML parsers in mail clients. (Actually, I'd personally advise you to not use any background image for all msgs. It upsets a lot of people.)
OS: Windows 2000 → All
Hardware: PC → All
Summary: url recognition transforms a url() CSS value inside a <style> tag → [mozTXTToHTMLConv] ScanHTML runs over head section, "recognizes" links in CSS
Reporter (sorry for the spam), please fix your HTML to put the <style> in <head>. If I read the code correctly, you should see the same problem still (but at least your code is then right). If you do *not* see the problem anymore, then it wasn't a Mozilla bug at all.
Ben, please see Comment #8 where it is pointed out that there is no known way to place a stylesheet into the head section. If you know a way, please share. -- Gus
> there is no known way to place a stylesheet into the head section Then you can't use <style> here.
Ability to place html into the head section would be ideal. Since this is not possible at this time, the situation remains that a background image may only be placed in body with html. In a div, table or td one cannot place a background image with either html or css. Realizing that using an embedded stylesheet in the body section is not conforming, but there is no alternative. With this method, background images do not work. Using an external stylesheet *works* for body, div, table and td, however since one is unable to access the head section, one is again forced to be non-conforming in placing the link into the body section. -- Gus
You can also put plastic coins instead of money into the vending machine, but don't complain when it doesn't work.
See bug 142366. You can create a template with a proper <head> structure by editing the Templates mbox file directly; however, when you load the template, Moz ends up moving all the content from the <head> into the <body>, among other problems. I haven't found an existing bug yet that addresses the inability to edit the <head> of the message. That isn't *this* bug, however. Also of possible interest: bug 57737. While I believe Ben's comment 11 probably correctly explains the mechanism of what's going wrong here, it seems pretty lame to simply say "you can't use <style>," and downright insulting to mock the user for "putting plastic coins... into the vending machine" when Mozilla doesn't support using "money." As it happens, Mozilla is robust enough to render the mail correctly even with <link> or <style> in the <body>, but that's not much help if the receiving mail client doesn't follow suit. I think the new summary of this bug is *less* accurate than the previous one, since the described symptom has nothing to do with <head> -- in fact, Ben claims that putting <style> into <head> would *prevent* this symptom (and that might be true were it not for bug 142366). The fact is, Mozilla's HTML composer is not ready for advanced use; this bug is but one symptom of that. Ben Bucksch: > You save the msg as Draft (from HTML Composer). Assuming your mail send > format option is not "as plaintext", the msg shoudl get saved as HTML. From the HTML composer, the draft is apparently *always* saved as HTML, no matter what options have been set.
Regarding Comment #7 - it only works when you check it locally. When actually sending it, it is not converted to a CID. Regarding Comment #9 - I tried it and it does not work. No CID conversion. Mike, It should not be necessary to create a template with a proper <head> structure by editing the Templates mbox file directly. Although this may be a solution for someone needing to include a repetetively used <link> in the head, it's not a solution for someone with varying external stylesheet needs. 142366 has been marked as FIXED. I don't believe that the FIX will affect this bug. "lame" as in "condescending", "antagonizing" or "smart-ass"? Ben, After a suitable calming down period, here is a highly edited and toned-down version. Regarding your comments: "I agree with the reporter that this is a low priority bug, this is nothing Mailnews tries to support." "Actually, I'd personally advise you to not use any background image for all msgs. It upsets a lot of people." I can see your interest in this bug is lacking. Do you note that there is interest from others? When advised that your advice, to place <style> in the head, is not possible, your response: "Then you can't use <style> here." Furthermore, when advised of what *does* work, but in a non-conforming way due to another bug in Moz, with an External Stylesheet, your response: "You can also put plastic coins instead of money into the vending machine, but don't complain when it doesn't work." Both remind me of a doctor telling the patient, who complains of pain when he raises his arm, to then not raise his arm. Funny from the doctor's point of view, but not so from that of the patient. Are you interested in receiving bug notifications and seeing about getting them fixed? -- Gus (also sorry for the spam)
Well, there are quite a few Inovative and creative folks that are being "handcuffed" by this attitude. If you write perfectly valid CSS into a composition, why shouldn't that code be executed. The answer, I am sad to say, is that some folks have "decided" otherwise. About 8 months ago in a bug discussion, the following comment was made: Wytigfyisagftw: What You Think Is Good For You Is Not Always Good For The Web. "Plastic Coins" is almost as bad. And just who are those, that make these arrogant decisions. Take a look at this discussion and decide for yourself
My reference to bug 142366 was a misdirection; the applicable item is bug 192557.
(In reply to comment #18) > Regarding Comment #7 - it only works when you check it locally. When actually > sending it, it is not converted to a CID. Pierre is using an http: URL for his background image; by citing the URL within a style attribute instead of within a <style> tag, it is not converted at all: neither into the unfortunate "URL-recognition" syntax -- which is quite incorrect in this context and is what Pierre complained about originally -- nor into a cid: URL. It would be consistent for Mozilla to attach the remote image and convert the URL to a cid:, but so long as the image remains at the URL and the receiver maintains an internet connection, the received mail will be readable as expected. (Note that bug 176416 seeks a way to *prevent* remote images from being attached to the message.) A file: URL is also not converted; that ought to be, along with the image being attached. But that's not what this bug is about.
Summary: [mozTXTToHTMLConv] ScanHTML runs over head section, "recognizes" links in CSS → [mozTXTToHTMLConv] ScanHTML "recognizes" links within <style>
Sorry if I insulted you. It just sounded strange to me to file a bug that <style> in <body> doesn't work. It's not *supposed* to work. It doesn't make sense to answer "but the other means don't work either". That doesn't make your attempted way any more valid. The bug as reported here is no bug at all. If a(ny) HTML renderer doesn't support a certain body tag, it conventionally simply ignores the tag and displays its content as normal text. So, if you put <style> into <body> and don't even protect it with HTML comments like Neil suggested, then you risk that some HTML parsers and renderers display your CSS rules as text to the user. This is basically what's happening here. The parser doesn't know about <style>, ignores it and treats its content as normal text. It acts fully within the conventions for HTML parsers/renderers. Making ScanHTML act as you expect for <style> inside <body> would be a hack. The next guy wants to have <script> in <body> etc.etc. To support all the invalid HTML that people write would require a complete rewrite of the function, by using the full-blown Mozilla parser, which would be slower and a *lot* more code. So, to be clear: Supporting <style> inside <body> for ScanHTML is WONTFIX/INVALID, for these reasons. Even if Mozilla would support it, you would still have the risk that the recipient renderer displays your CSS as text. So, it's a very bad idea to put <style> into <body>, independent of any Mozilla behaviour. If you would have put the <style> into the <head>, you'd still see the same problem. *That* would be a bug, and that's what I turned this bug report into. To make use of that, you *also* need to file an enhancement request to allow you to add HTML to the <head> section in the composer. This has nothing to do with this bug.
Summary: [mozTXTToHTMLConv] ScanHTML "recognizes" links within <style> → [mozTXTToHTMLConv] ScanHTML runs over <head> -> "recognizes" links in <style>
Ben, Just to be clear, it is agreed that using the method of placing the <style> in the <head> is non-conforming. Ref: Comment #8 and Comment #15 However, it is out of the user's hands since he only enters the <style> followed by the document content in a compliant way since the <body> tag is optional per /DTD HTML 4.01 Transitional/ which is what the Mail Client uses. It is the Mail Client which throws in the <body> tags and places the <style> in the <body> section. That being said, I agree that *all* optional <body> tags should be used and that the user *should* have access to the <head> for directly placing <style> and <link> therein (and the ability to edit same). In light of the above, should I still "file an enhancement request to allow you to add HTML to the <head> section in the composer", as you suggest? Gus
> In light of the above, should I still "file an enhancement request to allow you > to add HTML to the <head> section in the composer", as you suggest? I don't know (and don't care much), but maybe bug 192557 (which Mike mentioned) helps you?
Thank you. That's the one. Active discussions with a patch submitted.
Bug 192557 is now fixed. How does that affect this bug?
In addition to background image not working, background color does not work either now. --Gus
Sorry, I should have included: Using Thunderbird 0.6+ (20040510)
Sorry, not my day I guess - Correction: Using Thunderbird 0.6+ (20040610)
The symptoms of this bug are still there, and background-colors is not rendered, but I don't think it't due to Niel's patch. Somewhere between version version 0.6+ (20040604) 0.6+ (20040610) css background-color is not applied at all even on previously saved messages.
(In reply to comment #26) > Bug 192557 is now fixed. How does that affect this bug? The original problem, where a <style> tag had been entered into the mail via Insert|HTML, and the background-image url within the style had been converted, still exists; no surprise there. Ben's assertion that the same problem would occur on a <style> tag within the <head> has been borne out: now that the <style> will stay put within the <head> (after you go to the effort of manually creating such a template), the url is converted in that position as well. Again, no surprise. (In reply to comment #22) > Making ScanHTML act as you expect for <style> inside <body> would be a hack. > The next guy wants to have <script> in <body> etc.etc. I don't think it's that much of a hack. It's not like these tags are going to proliferate like rabbits; <style> and <script> are it for tags that have non-HTML content. (And in fact, <script> is *legal* within <body>.) > To support all the invalid > HTML that people write would require a complete rewrite of the function, by > using the full-blown Mozilla parser, which would be slower and a *lot* more > code. So, to be clear: Supporting <style> inside <body> for ScanHTML is > WONTFIX/INVALID, for these reasons. Well, I think that is a copout, for the reason I stated above. scanHTML *ought* to be suppressing recognition within <script> because that tag *is* legal, and adding support for <style> at the same time should be trivial. I am skeptical of the claim that a full rewrite of the scanner is necessary to handle this case. The functionality for skipping the content of the <a> tag is already there -- and isn't that how you proposed to handle skipping the content of the <head>? I can see no good reason not to include <script> and <style> in that small set. > Even if Mozilla would support it, you would still have the risk that the > recipient renderer displays your CSS as text. So, it's a very bad idea to put > <style> into <body>, independent of any Mozilla behaviour. I agree with this; I still think changing the scanner to skip only <head> is an insufficient approach. The RFE for compose-time control over the <head> of the message has yet to be opened, as far as I can find. Bug 143593 and bug 124506 are related. Re: comments 27-30: The background color thing is a red herring that is unrelated to the issue of the url being converted -- which is WHAT THIS BUG IS ABOUT.
Product: MailNews → Core
*** Bug 288570 has been marked as a duplicate of this bug. ***
I think bug 315191 is a dupe of this one. That bug mentions that there is an extension that allows editing the HTML in an HTML message, apparently including the <head>: <http://nic-nac-project.de/~kaosmos/edithtml-en.html>
*** Bug 315191 has been marked as a duplicate of this bug. ***
As an additional bit of information, the recent dupe has the invalidly transformed URL changed to: url(<a class="moz-txt-link-freetext" href="http://.../image.jpg">http://.../image.jpg</a>); That is, "moz-txt-link-freetext" rather than "moz-txt-link-rfc2396E". I checked and the CSS in this bug's original report was still changed to the -rfc2396E variation with TB 1.5b2-1006.
> I checked and the CSS in this bug's original report was still changed to > the -rfc2396E variation with TB 1.5b2-1006. (Yeah, the quotes. A valid URL, surrounded by " or <>, is the rfc2396 mode. But not terribly important for this particular bug, of course.)
I realized, if I send the URL in <style> without quotes, it sends this: <a class="moz-txt-link-freetext" href="http://.../image.jpg">http://.../image.jpg</a> if I put it into quotes, it sends the same, but with class="moz-txt-link-rfc2396E" Hope it helps!
(In reply to comment #9) I had the same problem commenting didn't seem to work, but didn't try real hard. I used a <base> command and removed the http: from the url in the style: <base href="http://grant4congress.com" /> background: url(./img/background_body_grey.gif) top center repeat-y; > CC'ing the author of the URL recognizer, but it might be possible to work > around > the problem like this: > <style> > /* <!-- fool the URL recognizer */ > #div > { > background-image:url("http://www.somewhere-on-the-web/image.png"); > } > /* end fooling the URL recognizer --> */ > </style> >
I have this anchor-replacement problem when I using signatures, read this post for more info: http://forums.mozillazine.org/viewtopic.php?p=2535298 I'm the only one on my office that is using Thunderbird , but because of new mail-signature policies I'm now forced to use Outlook when I'm sendeing mails to customers (wich I can assure is a real pain in the ass), so I can not realy get how this bug can be marked as minor, I think it shall be marked as major and be fixed as soon as possible, because for some people it is a real blocker...
Try putting your CSS in a style="" attribute instead of the <style> element (which is illegal in <body> anyways).
(In reply to comment #40) > Try putting your CSS in a style="" attribute instead of the <style> element > (which is illegal in <body> anyways). This results in something even more odd, when doing this, the div-tags with the style-attribute is completely stript away...
(In reply to comment #41) > This results in something even more odd, when doing this, the div-tags with the > style-attribute is completely stript away... Ah, by putting a &nbsp; inside the empty div it stayed... and now it seems to work. Thanks!
> div-tags with the style-attribute is completely stript away... No. I just tried it. Reproduction 1: 1. In HTML composer, do "Insert|HTML...", type <div style="color: green">test</div> 2. Send to self, do "View|Message source". Actual = expected result Reproduction 2: 1. Create file foo.html with content <div style="color: green">test</div> 2. In account prefs, Identity, specify that foo.html as signature 3. Create new HTML mail. You see the green "test". 4. Send to self, do "View|Message source". Actual = expected result
(In reply to comment #43) > No. I just tried it. Try this instead and see that the div is actually removed from the source. <div style="background:transparent url(http://www.mozilla.org/images/feature-logos2.png) no-repeat top left;"></div> If you put a &nbsp; it will stay though.
(In reply to comment #44) > (In reply to comment #43) > > > No. I just tried it. > > Try this instead and see that the div is actually removed from the source. > > <div style="background:transparent > url(http://www.mozilla.org/images/feature-logos2.png) no-repeat top > left;"></div> > > If you put a &nbsp; it will stay though. > Well...I've tried all manner of work-arounds to get this to work. And this <br> in div seems to do the trick. Nice catch. My list of workarounds for html is getting so..so..long. Let's hope this one is not considered a bug for an immediate fix action.
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: esther → composition
Product: Core → MailNews Core
Depends on: 964024
Bug 964024 was morphed to cover this, and just landed on the integration branch.
Status: NEW → RESOLVED
Closed: 10 years ago
No longer depends on: 964024
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.