Closed Bug 1699837 Opened 3 years ago Closed 3 years ago

Remote frames are zoomed in or out when printing to PDF


(Core :: Printing: Output, defect, P3)




Fission Milestone M7a
Tracking Status
firefox-esr78 --- disabled
firefox86 --- disabled
firefox87 --- disabled
firefox88 --- disabled
firefox91 --- fixed


(Reporter: jdescottes, Assigned: emilio)




(6 files)

I mentioned this in Bug 1695806, but I think it's worth filing a separate bug to make sure this gets properly triaged.


ER: The content of the remote frame should look the same as without fission
AR: The content of the remote frame is zoomed out

Fission Milestone: --- → M7a
Flags: needinfo?(emilio)

When I print the same page as PDF with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:88.0) Gecko/20100101 Firefox/88.0 ID:20210312033752 the remote frames content is zoomed in. So maybe it's system / platform dependent what actually happens?

Summary: Remote frames are zoomed out when printing to PDF → Remote frames are zoomed in or out when printing to PDF

So I dug into this a bit and I'm pretty sure that this is due to the various page scales etc not applying to the remote iframe. So somewhat a Graphics issue.

This is very visible on a test-case like this. The red area should always be half of the content area, but it is scaled up because we don't seem to account for the page scale transform that shrinks the iframe.

Tim, do you happen to know how do we compute effective scales for remote content like this?

Flags: needinfo?(emilio) → needinfo?(tnikkel)

For non-wr I think we send the scale to the child here

and we use that value in the child here

For wr I'm not sure how it works, the corresponding wr call to AddEffectUpdate just sends a unit scale. So maybe when wr rasterizes in the gpu/parent proc it assembles the wr display list and has all the info it needs that way?

Flags: needinfo?(tnikkel)
Depends on: 1700379
Blocks: gfx-triage
Assignee: nobody → emilio
Severity: -- → S3
Priority: -- → P3

Looks like layout folks have this one.

No longer blocks: gfx-triage

Emilio, gentle reminder about this M7a issue assigned to you. :)

Flags: needinfo?(emilio)
Depends on: 1709062

Yup, I was blocked on some snapping issues, but bug 1709062 allows me to dig into them and fix them.

Flags: needinfo?(emilio)
Blocks: 1710059
No longer blocks: 1710059
Depends on: 1710059

This fixes it since we honor the print resolution properly now. However
print setting updates are still broken.

The subdocuments do use it. Without fission, we don't have dynamic
visible area changes, but with the incoming patches we will.

Attachment #9222245 - Attachment description: WIP: Bug 1699837 - Make sure that remote iframes honor print settings. → Bug 1699837 - Make sure that remote iframes honor print settings. r=mattwoodrow

This is just cleanup while I was looking at why the test still fails
sometimes locally even with my patch. It is a bit racy because
BrowserChild's visible rect is not set by the time we do the
cross-process paint, so we clip everything...

This doesn't affect users and I have some upcoming PTO though, so will
look into it when I'm back.

Depends on D115263

Pushed by
Invalidate style for visible area changes in subdocuments. r=mattwoodrow
Keywords: leave-open
Pushed by
Use a few more typed units in CrossProcessPaint. r=mattwoodrow
Pushed by
Make sure that remote iframes honor print settings. r=mattwoodrow
Pushed by
Make sure that remote iframes honor print settings. r=mattwoodrow
Flags: needinfo?(emilio)
Closed: 3 years ago
Resolution: --- → FIXED

Hi Emilio,

This patch breaks builds that have printing disabled, since BrowserChild.cpp now includes nsDeviceContextSpecProxy.h which itself includes mozilla/layout/printing/DrawEventRecorder.h that is not included because of

What is the best way forward here? Should we consider that it's not possible anymore to disable the printing support and recognize that clearly by removing --disable-printing, or is there a sane way to #ifdef our way around this patch?

Pushed by
Follow-up: Fix --disable-printing builds.
Regressions: 1716537
You need to log in before you can comment on or make changes to this bug.