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
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
