New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: webContents.capturePage()
for hidden windows on Windows/Linux
#39730
Conversation
webContents.capturePage
for hidden windows on Windows/LinuxwebContents.capturePage()
for hidden windows on Windows/Linux
Needs a rebase to address build failures. |
a751f05
to
641d91a
Compare
5de00cc
to
44010fc
Compare
47397ad
to
f08bebf
Compare
f08bebf
to
4aff217
Compare
4aff217
to
8353209
Compare
Release Notes Persisted
|
I have automatically backported this PR to "28-x-y", please check out #40185 |
I have automatically backported this PR to "25-x-y", please check out #40186 |
I have automatically backported this PR to "26-x-y", please check out #40187 |
I have automatically backported this PR to "27-x-y", please check out #40188 |
Description of Change
Closes #31992.
Refactors a previous choice made to return an empty image for occluded windows when using
webContents.capturePage
on Windows and Linux. This was done to address an issue whereGetRenderWidgetHostView::CopyFromSurface
didn't call its callback in some occlusion cases. The original issue occurred because when a given page is hidden, the compositor called the provided callback immediately without posting it to the main thread - the worker thread then deadlocked as it tried to acquire the lock guarding thePromise
returned bywebContents.capturePage
held by the main thread. This second approach instead creates aOnceCallback
that will runOnCapturePageDone
via theUIThreadTaskRunner
.This is done in several upstream callsites.
Checklist
npm test
passesRelease Notes
Notes: Fixed an issue where fully occluded windows would return an empty image from
webContents.capturePage()
on Windows and Linux.