User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36 Steps to reproduce: I've created an HTML signature file and I set it up for my mail account as signature. Actual results: I have send a new created email with this new signature included. The appearence of the HTML signature was semitransparent. Expected results: When I want to print the sended mail to my printer, the signature appears just a part of it, not the entire signature and not at the end of the mail, but at the half of the page ... I will attache the signature file wich i use it, and the printed resoult printed as PDF.

Confirmed, I see the same on an aurora build. Apparently the signature is printed with an offset and then cropped, thus not entirely contained in the designated box or possibly even outside of the printable area.

Printing a notification e-mail from bugzilla (plain-text message) results in the signature being placed outside the printable area, so that case is confirmed as well.

print preview is fine, the printed version is not

Seems to be a cross-platform problem as it's reproducible on Linux as well.

Per bug 922303 comment #2, printing of the signature in an HTML message doesn't print it when using Original or Simple HTML, but /does/ print it when using Plain Text view (in which case the signature isn't grayed out either, thus may not be recognized as such). Plain-text messages with proper signature delimiter won't print a correct signature per comment #2 here.

Print will not print a table that has opacity set to anything less than 1.0 So it has nothing to do with the fact this shows in a sig, other than the fact that <div class="moz-signature"> applies an opacity=.6 Another curious phenom is that if you print a normal sig (with opacity=.6) while in a compose window, the sig prints fine.

Great. :-\ So after some searching, this is basically bug 768350 (<div>) which in turn was duped to bug 700003 (<table>). Thus, the expected regression window should be around 2011-05-27 if the signature was rendered with opacity back then already (which it wasn't, hence the bug never materialized).

Bug 697735, "SVG text element offset during printing for opacity < 1" is another candidate, specifically for the signature offset and bad cropping observed with image signatures (or tables containing images, see testcases).

Confirming comment #8, the regression window coincides with changing the signature from fixed colors to opacity in bug 855135: Last working build: TB 23.0a1, 2013-04-02 First affected build: TB 23.0a1, 2013-04-03 comm-central changeset 4ad03358510a Options: Waiting for either bug 700003 to be fixed or bug 917906 reverting from opacity to fixed colors again; or, adding some @media rule to exclude opacity from the signature (that would be the easiest solution in the short term and shouldn't put any constraints on bug 917906).

FWIW, enclosing the signature-opacity rule in "@media not print {...}" in messageQuotes.css fixes the issue and the signature is printed in full opacity, without any offset. So that's a feasible solution, if we want to go this route.

Here the patch for all Thunderbird and SeaMonkey default themes, if you want to try (full opacity for signatures by disabling the rules when printing).

Applied the patch in a local build (Win7) Worked fine. Printed at full opacity, and displayed at .6 as noted above.

Comment on attachment 812647 [details] [diff] [review] Work around bug 700003 Joe, thanks for testing. Since it seems possible to fix bug 917906 while retaining the opacity feature, I'm asking to review this as it's needed.

Comment on attachment 812647 [details] [diff] [review] Work around bug 700003 Review of attachment 812647 [details] [diff] [review]: ----------------------------------------------------------------- Looks good.

Comment on attachment 812647 [details] [diff] [review] Work around bug 700003 Seems reasonable to me by code inspection.

Well, **** - saw the update for 24.0.1, and was hoping this fix was included. Anyway, glad to see a fix is on the way... thanks to the devs! Any chance a new update will be pushed out asap after this fix is in? My users are driving me batty about it... ;)

(In reply to Charles from comment #20) > - saw the update for 24.0.1, and was hoping this fix was included. Yeah, me too... I've got caught by surprise, this would have been a nice ride-along. Pending in-time ui-review, the next regular release is for scheduled October 29th.

Hi guys. The 24.0.1 version appears but the bug still remain unfortunatly ...

Comment on attachment 812647 [details] [diff] [review] Work around bug 700003 It would be nice to be able to print non-fully-opaque things, but printing the signature seems more like what we want than not printing it, so ui-r=me.

the v 24.0.1 released but the bug still remains ...

Unfortunately this missed the intermediate 24.0.1 release while waiting for the ui-review (which we have now, thanks Blake). FYI, the remaining process is as follows: 1. The patch has to land on the development branch (trunk); 2. I'll have to derive a patch for the branch 24.0.2 comes from; 3. that (along with the other branches) will have to be approved; 4. then the branch patch can check in for the next release. Thus, the next update will hopefully cover this issue. Push for comm-central once the tree reopens, please.

This patch was built against comm-esr24 and also applies to comm-beta. [Approval Request Comment] Regression caused by (bug #): bug 855135, bug 855684; triggering bug 700003 User impact if declined: signatures not printing correctly or not at all Testing completed (on c-c, etc.): tested against current trunk and release builds Risk to taking this patch (and alternatives if risky): low

Comment on attachment 812647 [details] [diff] [review] Work around bug 700003 This patch also applies against comm-aurora. [Approval Request Comment] See comment #26.

Mark, I don't know what your plans are for the TB 25.0 beta, but please approve the branch patch for comm-beta as well so that it can land for SM 2.22 (SeaMonkey owners can't approve MailNews Core patches for the branches, afaik).

? Please tell me this doesn't mean that this fix won't make it into TB24??

Charles, "tracking-thunderbird-esr24: 25+" means that it is intended to land for the 24.0.x version that comes with the end of the 25.0 cycle, which would be now (or 24.0.2). And, hopefully bug 917906 will check in along with it.

Ok, thanks - and sorry... are these tracking flags documented somewhere so we could know what they mean without spamming the bug? By 'end of the 25.0 cycle', I assume you are referring to the Firefox 25.0 cycle (since the next TB major version will be 31 (or do I still not understand the new release cycle for Thunderbird?)? ;)

Strictly speaking, the *Gecko* 25.0 cycle (which happens to coincide with the FF and TB numbering now) given that it's MailNews Core rather than just Thunderbird. The ESR branch runs in parallel, that's where the 24.0.x builds are coming from. There should be a TB 25.0 *beta* shortly where this branch won't go into a release for Thunderbird though. http://forums.mozillazine.org/viewtopic.php?f=29&t=2033027

Pushed to trunk to get landed for branches: https://hg.mozilla.org/comm-central/rev/a8ce74502a6f

https://hg.mozilla.org/releases/comm-aurora/rev/9bcc64c7951e https://hg.mozilla.org/releases/comm-beta/rev/6f2c6f9d224c

Thanks Mark. I've filed bug 926924 to revisit this once bug 700003 has fixed the core issue (which I don't expect to happen any time soon, but now I still have it in mind).