Closed Bug 920997 Opened 6 years ago Closed 6 years ago

printing of signature is broken, positioning of signature in document subject to bogus offset and cropping


(MailNews Core :: Printing, defect)

Not set


(thunderbird25 fixed, thunderbird26 fixed, thunderbird27 fixed, seamonkey2.21 wontfix, seamonkey2.22 fixed, seamonkey2.23 fixed, seamonkey2.24 fixed, thunderbird_esr2425+ fixed)

Thunderbird 27.0
Tracking Status
thunderbird25 --- fixed
thunderbird26 --- fixed
thunderbird27 --- fixed
seamonkey2.21 --- wontfix
seamonkey2.22 --- fixed
seamonkey2.23 --- fixed
seamonkey2.24 --- fixed
thunderbird_esr24 25+ fixed


(Reporter: luka.levente, Assigned:


(Depends on 1 open bug, Blocks 1 open bug, )


(Keywords: regression, testcase, Whiteboard: [gs])


(3 files)

Attached file mybug.rar
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.
Summary: printing → printing of signature appears to be broken
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.
Component: Untriaged → Printing
Ever confirmed: true
Keywords: testcase
Product: Thunderbird → MailNews Core
Summary: printing of signature appears to be broken → printing of signature is broken, positioning of signature in document subject to bogus offset and cropping
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.
Duplicate of this bug: 919293
print preview is fine, the printed version is not
Seems to be a cross-platform problem as it's reproducible on Linux as well.
OS: Windows 7 → All
Hardware: x86_64 → All
Duplicate of this bug: 922303
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.
OS: All → Windows 7
Hardware: All → x86_64
OS: Windows 7 → All
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).
Hardware: x86_64 → All
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).
Blocks: 855135, 855684
Depends on: 700003, 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.
Hardware: All → x86_64
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.
Attachment #812647 - Flags: ui-review?(bwinton)
Attachment #812647 - Flags: review?(richard.marti)
Attachment #812647 - Flags: review?(neil)
Comment on attachment 812647 [details] [diff] [review]
Work around bug 700003

Review of attachment 812647 [details] [diff] [review]:

Looks good.
Attachment #812647 - Flags: review?(richard.marti) → review+
Comment on attachment 812647 [details] [diff] [review]
Work around bug 700003

Seems reasonable to me by code inspection.
Attachment #812647 - Flags: review?(neil) → review+
Assignee: nobody →
Duplicate of this bug: 923018
Duplicate of this bug: 919151
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.
Attachment #812647 - Flags: ui-review?(bwinton) → ui-review+
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.
Keywords: checkin-needed
Attached patch Branch patchSplinter Review
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
Attachment #816001 - Flags: approval-comm-esr24?
Attachment #816001 - Flags: approval-comm-beta?
Comment on attachment 812647 [details] [diff] [review]
Work around bug 700003

This patch also applies against comm-aurora.

[Approval Request Comment]
See comment #26.
Attachment #812647 - Flags: approval-comm-aurora?
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.
Pushed to trunk to get landed for branches:
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 27.0
Attachment #812647 - Flags: approval-comm-aurora? → approval-comm-aurora+
Attachment #816001 - Flags: approval-comm-beta? → approval-comm-beta+
Blocks: 926924
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).
Attachment #816001 - Flags: approval-comm-esr24? → approval-comm-esr24+
You need to log in before you can comment on or make changes to this bug.