Magic-Mirror/gecko-dev
1
0
Fork 0
mirror of https://github.com/mozilla/gecko-dev.git synced 2024-10-08 19:04:45 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Bug 1683188 - CrossProcessPaint code shouldn't mess with tab state from the content process. r=mattwoodrow,NeilDeakin

Browse Source 
There's JS running since we save the active status till we restore it,
so arbitrary things can happen, including receiving an IPC message from
the child saying that we're now really active.

If then we restore the wrong (old) status, stuff gets confused and
sadness ensues.

Screenshotting background tabs seems to work without this so it's not
clear to me why messing with the activeness state was necessary to begin
with.

Differential Revision: https://phabricator.services.mozilla.com/D101060
This commit is contained in:
Emilio Cobos Álvarez 2021-01-11 19:52:10 +00:00
parent 68f8f61866
commit e42e32baf8
1 changed files with 0 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
gfx/ipc/CrossProcessPaint.cpp
View File

@ -102,12 +102,6 @@ PaintFragment PaintFragment::Record(dom::BrowsingContext* aBc,
return PaintFragment{};
}
Maybe<dom::ExplicitActiveStatus> oldExplicitStatus;
if (!aBc->IsActive()) {
oldExplicitStatus.emplace(aBc->GetExplicitActive());
Unused << aBc->SetExplicitActive(dom::ExplicitActiveStatus::Active);
}
// Flush any pending notifications
nsContentUtils::FlushLayoutForTree(ds->GetWindow());
@ -142,10 +136,6 @@ PaintFragment PaintFragment::Record(dom::BrowsingContext* aBc,
thebes);
}
if (oldExplicitStatus) {
Unused << aBc->SetExplicitActive(*oldExplicitStatus);
}
if (!recorder->mOutputStream.mValid) {
return PaintFragment{};
}