Open Bug 1480547 Opened Last year Updated 18 hours ago
Fission: Support printing content with OOP iframes
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.
How much does this connect to the way compositing works? (Do we support partially-transparent iframes? That's certainly compositing...)
(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.
Summary: Support printing content with OOP iframes → Fission: Support printing content with OOP iframes
Fission Milestone: M4 → Future
Fission Milestone: Future → M6
You need to log in before you can comment on or make changes to this bug.