nsIClipboardDragDropHooks and nsIClipboardDragDropHookList allow XUL apps
to customize drag and drop operation and paste operation. However, this
feature was used only by ChatZilla and it doesn't work on Gecko anymore.
So, we can get rid of them from our tree.
MozReview-Commit-ID: Ibs3V1gI8Ry
--HG--
extra : rebase_source : 83428293d59aaca432d76c71b214aa7799f7f9de
This patch moves all TLS error string handling to the frontend.
Dev-tools doesn't show the same error code as the page does anymore but only the error code as string.
All logging of these error messages has been removed.
Bug #: 1415279
Differential Revision: https://phabricator.services.mozilla.com/D607
--HG--
extra : rebase_source : 61e2d94cb21ef4c02b81448531609205c85a9707
Improves the UI for pages blocked by the enterprise policy manager. These improvements include a new image instead of the generic "info" image and updated, approved strings for the page.
MozReview-Commit-ID: 9d6V9onHGGg
--HG--
extra : rebase_source : d702947924f24d9440455a56b7e2f876ab634464
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
