Office365's e-mail print results wasted spaces in both PDF & physical outputs.
Categories
(Core :: Printing: Output, defect, P1)
Tracking
()
People
(Reporter: ant, Unassigned)
References
()
Details
(Keywords: regression, regressionwindow-wanted)
Attachments
(3 files)
Office365samplePDFInFirefox68macOSsierra10.12.6.gif
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4
Steps to reproduce:
- Log into an Office365 account with Firefox v68 in mac OS Sierra v10.12.6.
- Access its email feature and read an e-mail.
- Use its print option (not from Firefox) to print it.
- Either print physically to paper or use its PDF preview.
- Look at its print results.
Actual results:
Print results (PDF and physical papers) show their whole first page 1 with huge e-mail title/subject wordwrapping very early taking up multiple rows to leave huge empty white gaps. And then, smaller/normal font sizes with To and CC e-mail addresses inside huge boxes. Under them, three horizontal lines and an empty box! All of these are the first page. A waste of precious page and time! Its e-mail body is on the second and on pages. See my attached Office365samplePDFInFirefox68macOSsierra10.12.6.gif / http://zimage.com/~ant/temp/Office365samplePDFInFirefox68macOSsierra10.12.6.gif for a censored sampler from a PDF print. :(
I also tried https://outlook.live.com, and it had no problems but I don't think that is a true Office365. Another user ran into this too in my https://www.reddit.com/r/firefox/comments/cbkc4v/is_anyone_else_having_problems_printing_from/etmi05z/ forum thread (still trying to get more details and did mention my bug report too).
Expected results:
First page should not have wasted white spaces and early wordwrappings.
|
||
Updated•6 years ago
|
This is not specific to MacOS or the official Office365. Today I noted the same exact behavior as described above on every Windows 7 machine which received the Firefox 68.0 update (dated 7/9/2019) when printing an email from a hosted exchange OWA (Outlook Web App). I fielded a bunch of calls about it and confirmed it on my own workstation and couldn't correct it with scaling selections in the printer driver at least on the HP P3015 which is shared between several machines in the office printing emails (lets not get into why they are printing the emails suffice to say they wish to continue).
Follow up - I confirmed that it seems to work fine in Windows 10. For me, the behavior described above only occurs in Firefox 68 under Windows 7.
Hello,
same problem on Windows 10, Windows 2008R2 and Windows 2016 with Firefox 68 update. After print test on outlook 365 online and gmail, bug appears when print from outlook 365 online but not from gmail.
Hi All,
we have similar printing problems in OWA365.
Up to Firefox version 67.0.4 (32bit) all right and starting from 68.0 (32bit) or 68.0.1 (32bit) the printout becomes very much smaller and unreadable. We use Win7 Prof. x64 and Win10 Prof. x64 and with both systems the same
I updated this morning to Firefox 68.0.1 and no change in this undesired behavior.
Our work around has been to double click the email you want to print in OWA to open it in its own window and then use the "hamburger" (three lines at upper right of that window) to open the Firefox dropdown menu and choose Print from there instead of using OWA's in-line print option. This seems to print most emails acceptably.
Nate: I assume only in OWA since it didn't work in Office365. :(
|
Reporter | |
Comment 10•6 years ago
|
||
Someone else mentioned this issue in my https://techcommunity.microsoft.com/t5/Office-365/Is-anyone-else-having-problems-printing-from-Office365-s-web/m-p/765274/highlight/false#M23535 forum thread too. More and more users are noticing this issue. :(
|
||
Comment 11•6 years ago
|
||
(In reply to nate from comment #8)
Our work around has been to double click the email you want to print in OWA to open it in its own window and then use the "hamburger" (three lines at upper right of that window) to open the Firefox dropdown menu and choose Print from there instead of using OWA's in-line print option. This seems to print most emails acceptably.
When we try to print this way, our printouts are empty. Only header and footer where printed...
such as titel, date and so one
|
||
Comment 12•6 years ago
|
||
Hey there,
As most users here, my company experience this bug on WIn7 32/64 or Win10 64 as soon they update to V 68.0 or 68.0.1
I have made some test and found a little workaround I didn't see in the comment. Since Firefox V 68.0.1 we now successfully print our mail using the "NEW Outlook trial/beta".
When switching to this test version, our mail now print properly.
Switching back to the normal version, mail suffer again of this weird printing (header / wasted blank)
Sir Ant, can you test if you have the same behaviour ?
Hope it can help in anything with this problem.
Have a nice day
|
|
||
Comment 13•6 years ago
|
||
I can confirm this workaround!
Our printouts are now normal back...
Thanks for this helpful information!!!
|
||
Comment 14•6 years ago
|
||
In our case we do not have such an option for "New Outlook trial / beta" because we are on a hosted OWA (not direct with Microsoft, not on Office 365) which might be version 2016? In any case we do not have a way to change OWA to any newer version until such time the hosting company decides to upgrade it.
|
||
Comment 15•6 years ago
|
||
Hi ant and nate, if you can't use the "new Outlook" we have some workaround discussion on SUMO, but it's not convenient or conclusive: https://support.mozilla.org/questions/1265353
|
||
Comment 16•6 years ago
|
||
I have the same problem on exchange webmail, if we try to print a sent email, we just get the header and footer and nothing else. Like @nate we also don't have anyway to change OWA to a newer version. Fingers crossed this gets sorted soon, at present having to use Chrome to get round the problem.
|
|
Reporter | |
Comment 17•6 years ago
|
||
http://usc.edu/office365 does have the new Outlook option. However, how much is changed? Is it a beta? Can the user revert back to old one if there are issues?
|
|
||
Comment 18•6 years ago
|
||
(In reply to Ant from comment #17)
Can the user revert back to old one if there are issues?
Yes, the switch to revert back is in the same place in the new layout. You will need to use the Print button provided by the site because that does some additional formatting before printing.
|
|
Reporter | |
Comment 19•6 years ago
|
||
jscher2000: Perfect and thanks. It seems to work well. Its upgrade seems mostly the same to me too. This is still a problem for those can't get the "new Outlook".
|
|
||
Comment 20•6 years ago
|
||
The priority flag is not set for this bug.
:jwatt, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 21•6 years ago
|
||
Hi,
I am also confirming this bug exactly as shown in the examples for Outlook Web App printing. Cannot resolve the issue with any manipulation of settings, and the same emails print fine in Google Chrome or Microsoft Edge. Appears to me to be a confirmed bug. Happy to help with examples for the Mozilla team. Thanks. Barry
|
|
||
Comment 22•6 years ago
|
||
This is what I get using Mozregression-gui on Office 365:
2019-08-04T11:43:02: INFO : platform_buildid: 20190403115411
2019-08-04T11:43:02: INFO : platform_changeset: d71df181f3d948fa113de06223649f5e6298b47b
2019-08-04T11:43:02: INFO : platform_repository: https://hg.mozilla.org/integration/autoland
2019-08-04T11:43:02: INFO : platform_version: 68.0a1
2019-08-04T11:44:01: INFO : Narrowed inbound regression window from [2d7fcd11, 60c20a0f] (3 builds) to [d71df181, 60c20a0f] (2 builds) (~1 steps left)
2019-08-04T11:44:01: DEBUG : Starting merge handling...
2019-08-04T11:44:01: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=60c20a0f320cc769a8da229cdf6edfbbf38d3ed3&full=1
2019-08-04T11:44:02: DEBUG : Found commit message:
Bug 1535788 - Make the Document own the StyleSet. r=heycam
This is the last step to be able to call matchMedia on display: none iframes.
This is green, except for some startup preference query tests that I'm going to
address in a blocking bug (making LangGroupFontPrefs global, basically).
The setup is similar to the ShadowRoot one, except we don't eagerly keep the
StyleSet around up-to-date, we only fill it if it ever had a pres context.
Differential Revision: https://phabricator.services.mozilla.com/D23903
2019-08-04T11:44:02: DEBUG : Did not find a branch, checking all integration branches
2019-08-04T11:44:02: INFO : The bisection is done.
|
|
||
Comment 23•6 years ago
|
||
For clarity to the Mozilla team, this is not just a wasted space for the printout. The email header information is truncated, missing, and misplaced compared to the many years of it being fine. Printed emails are not usable. Happy to provide examples or more info if it will help. Warm regards. Barry
|
|
||
Comment 24•6 years ago
|
||
I can't reproduce the problem in Developer Edition (https://www.mozilla.org/firefox/developer/all/):
Version 69.0b10
Build ID 20190801185445
This might be fixed in the following patch added in 69.0b8 and Nightly before that:
Bug 1567105 Only the header and footer are Printed for emails in Outlook Webapp -- "Approved for 68.0.2 & 68.0.2esr"
Any anyone else reproduce the problem on beta/developer/nightly at this point?
Yes, this sounds like the same bug, and that fix has already landed in order to be in 68.0.2.
|
||
Updated•6 years ago
|
|
|
||
Comment 26•6 years ago
|
||
I can confirm that 68.0.2 has resolved the issue on Windows 7 when using hosted exchange OWA.
|
|
||
Comment 27•6 years ago
|
||
I can confirm that 68.0.2 has resolved the issue on Windows 10, printouts are correct....
|
||
Updated•6 years ago
|
|
||
Updated•6 years ago
|
Description
•