Here is the list of variables which are reset in nsDocShell::Destroy().
The right column shows the function where the variable is set. In this patch
all the functions other than SetTreeOwner(*1) have an assertion that we don't
allow the function to be called or bail out during destroying the docshell.
It is possible that SetTreeOwner() is called in script through
`browser.setAttribute("primary", "true")`. So we can't assert there, we just
bail out from SetTreeOwner when the docshell is being destroyed.
mInitialClientSource MaybeCreateInitialClientSource()
mObserveErrorPages: Initially true, never sets true again
mLoadingURI: CreateContentViewer()
mOSHE->SetEditorData(nullptr): DetachEditorFromWindow()
mLSHE->SetEditorData(nullptr): Setting again in RestoreFromHistory() after bailing out if mIsBeingDestroyed is true
mContentListener: Init()
Stop(nsIWebNavigation::STOP_ALL)
mRestorePresentationEvent: RestorePresentation()
mFailedChannel: LoadErrorPage()
mFailedURI: LoadErrorPage()
mRefreshURIList: RefreshURI()
mEditorData: ReattachEditorToWindow() and EnsureEditorData()
mTransferableHookData: EnsureTransferableHookData()
mContentViewer: SetupNewViewer()
mParentWidget: SetParentWidget()
mCurrentURI: SetCurrentURI()
mScriptGlobal: EnsureScriptEnvironment()
mSessionHistory SetSessionHistory()
SetTreeOwner(): SetTreeOwner() *1
mOnePermittedSandboxedNavigator: SetOnePermittedSandboxedNavigator()
mSecurityUI: SetSecurityUI()
CancelRefreshURITimers()
mRefreshURIList: RefreshURI()
mSavedRefreshURIList: RefreshURI()
mPrivateBrowsingId: SetPrivateBrowsing()
mOriginAttributes: SetOriginAttributes()
DecreasePrivateDocShellCount: SetAffectPrivateSessionLifetime()
MozReview-Commit-ID: G5d941R9K8V
--HG--
extra : rebase_source : 978e5b232e76a803c104c030bbeb91315d886491
The test case in this patch is harmless without this fix, no assertion happens,
no failure happens in the test, but nsDocShell::Destroy() is processed twice.
MozReview-Commit-ID: 2g949emc7at
--HG--
extra : rebase_source : 34209e5cd5310521b2eec4d4f67f355bfdae5d8d
Normally the docshell stops the content viewer in nsDocShell::Stop(), but in this
case it won't be stopped in that function since the new content viewer has never
been associated with this docshell.
dom/base/test/test_bug1126851.html is a test case that we bail out
from CreateContentViewer() due to win.close() in an unload event callback.
MozReview-Commit-ID: 7O7TmwHN9re
--HG--
extra : rebase_source : 8f50efd4b582d3283ad482fd896b5d558c0e8269
There are four call sites of FirePageHideNotification(). Two of them are
handled in this patch. The other two will be taken care of in the subsequent
patches in this patch series respectively.
Without this fix, the test case in this patch causes assertions when
cycle collection happens.
MozReview-Commit-ID: 6GSxjdfXGcY
--HG--
extra : rebase_source : 998b95ae90a1ad80dc177d5eecf1a592ba375116
We bail out the function to make sure we don't process CreateContentViewer
and mLoadingURI is not re-initialized in the function while destroying the
docshell.
MozReview-Commit-ID: AYJ1t2N786N
--HG--
extra : rebase_source : b02c6a061a8938936b40195e166ac2b6c187406d
This macro is identical to NS_INTERFACE_MAP_END and encourages the
reader to think that there's something extra-special threadsafe about QI
implementations that use the macro, when in reality there's nothing of
the sort.
Much in the spirit of bug 1434474.
We right now call MediaFeatureChanges sync or async pretty randomly. This has
caused bugs in the past like bug 1413143.
Unify media feature changes, and only post them async, and flush them from
FlushPendingNotifications.
This also fixes a pre-existing problem where style wasn't flushed correctly from
getComputedStyle when there were pending media feature values.
MozReview-Commit-ID: H9S1M8fk5H4
It's possible to RenderLayers for a top-level content process DocShell without that DocShell being
active. When we do this, the PresShell for that DocShell becomes active, but the DocShell stays
inactive (to avoid accidentally playing paused video or clearing notifications in that DocShell).
If a DocShell is inactive but rendering its layers, it's possible for that DocShell to navigate.
When this occurs, a new PresShell can be created, which normally reads its active state off of
the DocShell. This means that the PresShell will become inactive even though the tab is supposed
to continue rendering its layers.
This patch checks for PresShell active state when setting up a new content viewer after a navigation,
and if the previous PresShell was active, makes the new PresShell active too.
MozReview-Commit-ID: KX9HvZJKqg2
--HG--
extra : rebase_source : aac1710a64b6e5f93b9874b2a15637d94a8ce5b6
Yaroslav Taben
Hiroyuki Ikezoe
Kirk Steuber
Adrian Wielgosik
Nathan Froyd
Josh Matthews
Emilio Cobos Álvarez
Samael Wang
Boris Zbarsky
Ben Kelly
Andrea Marchesini
Brindusan Cristian
Nika Layzell
Jonathan Watt
Mike Conley
Chris Peterson
Ciure Andrei
Kate McKinley
Andrew Swan
Milan Sreckovic
Margareta Eliza Balazs
Alphan Chen
Sebastian Hengst