refactor: printToPDF should be headless - #33654
Conversation
0239b82 to
b84824b
Compare
1b29ac3 to
9bdd930
Compare
|
API LGTM |
9bdd930 to
7fdb8d2
Compare
itsananderson
left a comment
There was a problem hiding this comment.
Oops. I forgot how Github's review workflow works and didn't submit my comment.
|
@codebytere By the way, I'm seeing a similar issue when using the |
|
@pushkin- that's a totally different problem & there are already open issues for it :) |
7fdb8d2 to
f01e26e
Compare
Cool, I found this one. If that's the one you're talking about, can the "blocked" label be removed since there is a repro gist now? And can the version tag be updated? Thank you @codebytere |
4a9c361 to
ff5f370
Compare
ckerr
left a comment
There was a problem hiding this comment.
Full review forthcoming; just sending this one suggestion out for rn
ff5f370 to
0cbfd33
Compare
2cb7097 to
db2be74
Compare
|
Release Notes Persisted
|
Description of Change
BREAKING CHANGE
Closes #24947.
Closes #30753.
Closes #27605.
Closes #29324.
This PR refactors our
printToPDFimplementation to match that of Chromium's headless implementation, seen here. Per https://bugs.chromium.org/p/chromium/issues/detail?id=1101596, we'd hit the limit with our previous approach, since with out of process iframes enabled we were unable to properly composite subframes. This removes that hacked-together implementation in favor of headless'.Checklist
npm testpassesRelease Notes
Notes: Refactored
webContents.printToPDFto align with the Chrome Devtools implementation.