Print of PDF becoming corrupted
Categories
(Core :: Print Preview, defect)
Tracking
()
People
(Reporter: eclipsechasers2, Unassigned)
References
Details
(Keywords: regression, reproducible)
Attachments
(1 file)
105.77 KB,
image/jpeg
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0
Steps to reproduce:
Go to print preview, everything is okay.
Open another tab in same Firefox window, and click on several links on new tab. I used cnn.com, but other sites showed similar results. Number of clicks vary to demonstrate the problem.
After several clicks on the new tab, return to the pdf tab, and go to print preview. First two pages are corrupted.
Actual results:
Display within Firefox remains okay, but print preview (and print to printer) both wind up with corrupted first 2 pages - other pages are okay. This happens for admin and non-admin users on Win7 and Win10. It also happens on Ubuntu LTS 18.04.
Print preview shown in attached jpg. Unprintable bytes are displayed with "Unicode BMP Fallback SIL Regular" font.
Expected results:
Print preview (and print to printer) should print the document as shown in browser.
Updated•6 years ago
|
Updated•6 years ago
|
Comment 1•6 years ago
|
||
I can reproduce the issue on nightly66.0a1 windows10.
Reproducible: almost always
STR:
0. Start Nightly with new profile
-
Open https://volunteerhub.readingpartners.org/wp-content/uploads/2018/08/FY19-Volunteer-Clearance-Instructions_SFBA-DOJFBITB.pdf in [tab 1]
-
Open https://bugzilla.mozilla.org/enter_bug.cgi in [tab 2][tab 3][tab 4][tab 5][tab 6][tab 7][tab 8] (not need logged in)
-
Switch to [tab 1]
-
File > Print Preview
-
if not, exit print preview mode
-
Close [tab 2] to [tab 8] and then repeat from step 2
Comment 2•6 years ago
|
||
Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5097db630d1fb51f7f3fcd5523a924fa823e77ce&tochange=caa65bf34838ab7861dcfed3ae59f9f6ed89fc0b
Regressed by: caa65bf34838 Ryan VanderMeulen — Bug 1489996 - Update pdf.js to version 2.0.843. r=bdahl
Comment 3•6 years ago
|
||
@Ryan,
Your landing patch seems to cause the regression. Can you please look into this?
Comment 4•6 years ago
|
||
Changelog for that update:
(In reply to Ryan VanderMeulen [:RyanVM] from bug 1489996 comment #0)
#10049 Fix font-string variable name typo
#9995 Refactor code in theweb/
folder to useasync
/await
#10053 Simplify the "spaced-comment" ESLint rule
#10034 RemovegetSinglePixelWidth
workaround
#10054 Update translations/packages and use HTTPS for links inREADME.md
#10052 Display the index of the currently active search result in the
matches counter of the findbar (issue 6993, bug 1062025)
#10055 Translate the new find match count strings to Dutch
#10028 Add initial support for "Whole words" searching in the viewer
#10034 maybe? Or #10049 maybe.
Comment 5•6 years ago
|
||
This is pretty finicky, BTW. I've been able to reproduce it once with Fx64 so far using the STR from comment 1.
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment 8•6 years ago
|
||
Marking it as a duplicate of Bug 1518473. Was reported during 66 Nightly Validation, thanks for the regression range Alice!
Comment 9•6 years ago
|
||
In the future, it would be helpful to ensure that all the flags and requests get carried over when you dupe a bug. Also, the other bug wasn't tagged as a regression? We might have been able to have gotten a fix in time for 65 if it had shown up on that radar sooner :(
Comment 10•6 years ago
|
||
I'm sorry for the inconvenience Ryan, I only checked the latest Nightly 66, Beta 65 and Release 64 versions and marked the flags for those ones. Should've checked a bit further since your patch landed in 63 or so.
Will make sure to investigate more in the future and provide a reg-range asap.
Description
•