Audit whether it's right thing to do that we do create nsRootPresContext for subdocuments in print preview (maybe also in printing)
Categories
(Core :: Print Preview, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox82 | --- | fixed |
People
(Reporter: hiro, Assigned: hiro)
References
Details
(Whiteboard: [print2020_v82], [wptsync upstream])
Attachments
(2 files)
In bug 1661608 Botond noticed that we do create nsRootPresContext for subdocuments in print previewing documents. To me, it's simply wrong but I am not 100% sure right now, if it's wrong we should stop doing it.
| Assignee | ||
Comment 1•6 years ago
|
||
It comes from inside nsPrintJob::ReflowPrintObject, and it was introduced in bug 468568 comment 173 to avoid happening DidPaint in the subdocument's pres contexts. The bug 468568 aimed to be able to print downloadable fonts in print documents. In these days do we still need the hack introduced in the bug?
| Assignee | ||
Comment 2•6 years ago
|
||
From a review comment by Olli in bug 468568 comment 177 (it's not well-formatted though);
- aPO->mPresContext = aPO->mParent ?
new nsPresContext(aPO->mDocument, type) : NS_ENSURE_TRUE(aPO->mPresContext, NS_ERROR_OUT_OF_MEMORY);new nsRootPresContext(aPO->mDocument, type);In printpreview case if there isn't parent, shouldn't you check
DocumentViewerImpl::FindContainerView() so that we don't end up creating
rootprescontext in case pp is shown as a tab (like it usually is).
Whereas the current code is;
nsView* parentView = aPO->mParent && aPO->mParent->PrintingIsEnabled()
? nullptr
: GetParentViewForRoot();
aPO->mPresContext = parentView ? new nsPresContext(aPO->mDocument, type)
: new nsRootPresContext(aPO->mDocument, type);
So it looks it's not been what we wanted. In the current code, we do create nsRootPresContext in most cases.
Instead what we wanted is if (aPo->mParent && aPO->mParent->PrintingIsEnabled()) or GetParentViewForRoot() is not null, then we do create nsPresContext?
CCing, Olli.
| Assignee | ||
Comment 3•6 years ago
•
|
||
Olli, is my understanding in comment 2 correct? I've confirmed with the correction downloadable fonts is printed/print-previewed properly in an iframe.
If my understanding is correct, I am going to add a print reftest with a downloadable font (and add a print-preview test if I could).
Comment 4•6 years ago
|
||
hmm, my comment was even before e10s.
But yes, your suggestion sounds right. Top level thing should be RootPrescontext
| Assignee | ||
Comment 5•6 years ago
|
||
Thank you, Olli!
| Assignee | ||
Comment 6•6 years ago
|
||
| Assignee | ||
Comment 7•6 years ago
|
||
| Assignee | ||
Comment 8•6 years ago
|
||
Though there is no automated test for this change, I think the test cases in the
previous commit well cover the original issue (bug 468568) that downloadable
fonts are not rendered in printing.
Depends on D89095
| Assignee | ||
Comment 9•6 years ago
|
||
test_printpreview.xhtml failed on a TV run with "application terminated with exit code 2" but it actually failed before newly adding tests here;
So I think it's a pre-existing issue. (And I noticed there are a bunch of intermittent test failures on test_printpreview.xhtml, we should take a look of them).
Comment 10•6 years ago
|
||
Comment 12•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/986578cbad09
https://hg.mozilla.org/mozilla-central/rev/69fdf7a9f0ce
Updated•6 years ago
|
Updated•5 years ago
|
Description
•