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•4 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•4 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•4 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•4 years ago
|
||
hmm, my comment was even before e10s.
But yes, your suggestion sounds right. Top level thing should be RootPrescontext
Assignee | ||
Comment 5•4 years ago
|
||
Thank you, Olli!
Assignee | ||
Comment 6•4 years ago
|
||
Assignee | ||
Comment 7•4 years ago
|
||
Assignee | ||
Comment 8•4 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•4 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•4 years ago
|
||
Pushed by hikezoe.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/986578cbad09 Add wpts and mochitests to make sure downloadable font is properly printed or rendered in print preview. r=jfkthame https://hg.mozilla.org/integration/autoland/rev/69fdf7a9f0ce Generate nsRootPresShell for printing ducuments only if the document has no parent OR the parent is not going to be printed AND GetParentViewForRoot() is not null. r=smaug
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/25372 for changes under testing/web-platform/tests
Comment 12•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/986578cbad09
https://hg.mozilla.org/mozilla-central/rev/69fdf7a9f0ce
Upstream PR merged by moz-wptsync-bot
Updated•4 years ago
|
Updated•3 years ago
|
Description
•