Print preview - text not rendered properly if not loaded fully
Categories
(Core :: Print Preview, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox65 | --- | wontfix |
firefox66 | --- | fix-optional |
firefox67 | --- | fix-optional |
firefox68 | --- | wontfix |
People
(Reporter: cfogel, Unassigned)
Details
(Keywords: regression, Whiteboard: [layout:print-triage:p2][layout:backlog:quality])
Attachments
(1 file)
119.41 KB,
image/png
|
Details |
Affected versions
- 65.0.1, 66.0b7, 67.0a1(2019-02-06)
Affected platforms
- Windows 8.1, Ubuntu 16.04, macOS 10.13
Steps to reproduce
- new/fresh profile needed
- Access https://www.cambridgeenglish.org/images/153310-movers-sample-papers-volume-2.pdf
- Click on the Hambourger menu button;
- Click on the Print option (to open Print preview);
- Scroll down;
Expected result
- PDF content is properly displayed;
Actual result
- Characters are not displayed properly;
Regression range
** While trying to identify the regression range, there was a slight difference in the issue (text was not as badly affected but might be relevant)
Range_1
- First bad: 2018-07-02 22:58:42.315000
- Last good: 2018-07-02 22:30:24.654000
- Potential regressor: bug 1413794
- Pushlog URL: link;
Range_2
** Range for just the reported issue:
- First bad: 2018-09-11 01:03:16.065000
- Last good: 2018-09-11 00:38:36.520000
- Potential regressor: bug 1489996
- Pushlog URL: link;
Additional notes
-
on nightly - past 2019-02-07 the issue did not appear reproduce
-
attached screenshot with the issue;
-
issue reproduces even after the text is fully loaded, the summary seems to have a better reproduction rate;
-
issue persists on printed pages as well;
-
in some cases ex. for this file, on macOS the header+footer are affected;
-
the 60.0.1 (ESR) build behaves as in Range_1;
Reporter | ||
Updated•5 years ago
|
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 2•5 years ago
|
||
My issue does not reproduce on the latest nightly version, however the one mentioned in the bug above still happens.
If the fix would handle both the characters in the page and the ones from the print preview then yes, we can mark it as a dupe.
Updated•5 years ago
|
Reporter | ||
Comment 3•5 years ago
|
||
Added macOS as an affected platform, with the mention that the displayed characters are different.
ex: "wwwww" or "yyyyy" or "()()()()()()()".
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Hey Sean, what is the priority on this? (will this be fixed for 68?) Thanks!
Comment 5•5 years ago
|
||
We won't get this in time for 68, but I will get it on our backlog of printing bugs. Looks like another pdf.js issue.
CCing jwatt as an FYI.
Updated•4 years ago
|
Updated•2 years ago
|
Description
•