1480547 - (printing-fission) Fission: Support printing content with OOP iframes

Status: RESOLVED FIXED

(Core :: Printing: Output, enhancement, P1)

Description

[Ryan Hunt [:rhunt] (on leave until early May)]

I'm not sure if this is the right component for this. Feel free to move.

Currently we cannot render iframes from other content processes. This means that when printing with Fission enabled, there will be a blank space where any OOP iframes are located

Additionally, I don't believe it's desirable to allow a content process to request another content process to render itself as that could allow a compromised process to view the contents of a site of a different origin.

My understanding of printing is that it is driven by the parent process. It sounds like we'll need to update it to request prints/recordings of all necessary frames, and then merge them somehow.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

How much does this connect to the way compositing works?  (Do we support partially-transparent iframes?  That's certainly compositing...)

Comment 2

[Ryan Hunt [:rhunt] (on leave until early May)]

(In reply to David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7 from comment #1)
> How much does this connect to the way compositing works?  (Do we support
> partially-transparent iframes?  That's certainly compositing...)

Printing doesn't use the normal OMTC path of ClientLayerManager/
HostLayerManager/Compositor. It instead uses a BasicLayerManager on
the main thread that outputs to a draw target.

Without e10s, this is a device context draw target for the printer. On
windows I think this is cairo backed by GDI. With e10s, this is a draw
target recording that is sent to the parent process to be replayed on
a device context draw target.

We don't use the OMTC infrastructure for a couple reasons, but I think
the main one is that OMTC works by syncing textures for each layer
whereas printing needs the actual draw commands.

Comment 4

[Matt Woodrow (:mattwoodrow)]

We're explicitly not going to do printing for M4. Jonathan is going to work on getting Print Preview done for Q3, but it's not M4 as such.

Comment 5

[Chris Peterson [:cpeterson]]

M6 because printing support blocks enabling Fission in Nightly.

Comment 6

[Chris Peterson [:cpeterson]]

Tracking for Fission Nightly (M6c)

Comment 7

[Neha Kochar [:neha]]

Sean said fission printing work will most probably not be ready in time for nightly experiment and we shouldn't block on it. It is expected to be fixed in a couple of weeks following the experiment launch.

Comment 8

[Jonathan Watt [:jwatt]]

The push to try to get the new printing UI ready for v81 has been tough. v83 is the absolute best case scenario at this point, and that's only if it actually does take two weeks of work which would depend on dropping support for the old printing UI and GFX support. There are a bunch of "if"s and "but"s in play right now. Even then, I won't be surprised if it takes significantly longer than two weeks (that's based on general knowledge of all the bits of code involved and gut feeling, not on a proper investigation which we haven't had the cycles for yet and I'm guessing won't happen until Emilio and I have had some PTO to recharge).

needinfo only to make sure you see this and are updated, Neha.

Comment 9

[Neha Kochar [:neha]]

Thanks jwatt. I appreciate the info. I've talked with Sean and 83 soft freeze (Oct 15) is when we are going to try printing iframes to be done, and it will give us ~1.5 weeks after the experiment launch to get this fixed, and is an acceptable risk at this time.