Commit ad6fdeea authored by Emilio Cobos Álvarez's avatar Emilio Cobos Álvarez
Browse files

Bug 1683188 - CrossProcessPaint code shouldn't mess with tab state from the...

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

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
parent 80f441a2
......@@ -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{};
}
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment