Confirmed, TB 1.0 winXP
Status: UNCONFIRMED → NEW
Component: General → Mail Window Front End
Ever confirmed: true
Confirmed, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051003 SeaMonkey/1.1a, but only if View -> Message Body As -> Original HTML is set. Not Windows- and Thunderbird-only. Suggest changing "OS: Windows XP" to "OS: All".
Does the bug allow now system or user account compomise in connection with http://www.mozilla.org/security/announce/mfsa2006-05.html at least for Thunderbird 1.0.7 and 1.5?
WFM with latest versions of Thunderbird from 1.8.0 and 1.8.1 branches. Is this still an issue for SeaMonkey?
Assignee: mscott → nobody
Component: Mail Window Front End → MailNews: Printing
OS: Windows XP → All
Product: Thunderbird → Core
QA Contact: front-end → printing
Argh, ok, I completely misread this, blame last night. Yes, print preview shows the alert in SeaMonkey trunk even with JS disabled for MailNews. This looks really wrong.
Version: unspecified → Trunk
My SeaMonkey build from 1.8 branch also shows the bug (all my testing is Linux).
this might be as easy as making sure we set the mail app type (APP_TYPE_MAIL) on the root docshell for the print engine in nsMsgPrintEngine.cpp
Assignee: nobody → hskupin
Hardware: PC → All
Comment on attachment 271740 [details] [diff] [review] Patch v1: Set correct APP_TYPE This patch fixes it for me too. One thing to watch out for, I think this might start pushing print preview through the mail content policy manager. There might be issues with remote images and if you've allowed remote images for a message and then try to print preview, do those images load or are they blocked? Could be worth poking around at.
Attachment #271740 - Flags: superreview?(mscott) → superreview+
Scott, I cannot see any issue with remote images. I created a HTML message and saved it as draft. Opening the draft shows me an empty rectangle with the broken image sign. Opening the print preview the image isn't shown. Ok, that's like expected. After that I loaded the image for this message. It's visible inside the body. Opening once again the print preview shows me the image. No blocking of allowed remote images happens.
Status: NEW → ASSIGNED
Comment on attachment 271740 [details] [diff] [review] Patch v1: Set correct APP_TYPE Yeah, looks good. I did some testing with global and message specific remote content blocking and found that these settings are indeed honored by print preview now! (As are those for View HTML As...)
Attachment #271740 - Flags: review?(mnyromyr) → review+
cool! I think this patch is ready for the trunk. I'll land it for Henrik. Thanks Henrik!
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Verified with version 3.0a1pre (2007071403).
Status: RESOLVED → VERIFIED
Attachment #271740 - Flags: approval126.96.36.199?
Comment on attachment 271740 [details] [diff] [review] Patch v1: Set correct APP_TYPE Asking approval accordingly to blocking flags.
Comment on attachment 271740 [details] [diff] [review] Patch v1: Set correct APP_TYPE approved for 188.8.131.52, a=dveditz for release-drivers
Comment on attachment 271740 [details] [diff] [review] Patch v1: Set correct APP_TYPE Landed on MOZILLA_1_8_BRANCH and MOZILLA_1_8_0_BRANCH.
You need to log in before you can comment on or make changes to this bug.