Make nsDocumentViewer::SetPrintPreviewPresentation correctly handle attaching to toplevel widgets

RESOLVED FIXED in mozilla35

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Tracking

unspecified
mozilla35
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10sm3+)

Details

Attachments

(1 attachment)

This is needed for bug 927188.  Otherwise we never attach the print-preview presentation in the child process to the puppet widget and end up not painting it.
It's not clear to me, by the way, whether it's best to do this, or to set it up in the print code wherever we create the viewmanager...   This seemed pretty sane and safe to me, though.
Blocks: 927188
Comment on attachment 8489521 [details] [diff] [review]
Hook up print preview to our parent widget as needed, so it will actually paint.

Looks pretty sane. The view handling stuff in printengine doesn't currently
deal with printpreview explicitly, and since SetPrintPreviewPresentation
is explicitly for pp, this should be fine.

Other option is to modify nsDocumentViewer::MakeWindow and nsPrintEngine::SetRootView( quite a bit.
Attachment #8489521 - Flags: review?(bugs) → review+
Yeah, I'm all in favor of not modifying things more than needed here.  ;)
https://hg.mozilla.org/mozilla-central/rev/9db811d45df1
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
You need to log in before you can comment on or make changes to this bug.