This patch removes the object iterator implementation that was used to fix bug 1317019 in favor of using Object.entries() when recording method-level JS code coverage through the JS Debugger.
MozReview-Commit-ID: AxeG5QglwRm
--HG--
extra : rebase_source : 36a09469ddf1a9a6fa0954aadc53534a4308d2b0
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#16107
- [X] There are tests for these changes
Source-Repo: https://github.com/servo/servo
Source-Revision: a6113af87335d69d11e53bc0ef2618dc7f6d16a0
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : e25dc9d4f6a0e66cb91b06e6232d5311f237ea74
This patch just removes the following styles from these reftests:
border-block-start-color: orange;
border-inline-start-color: lime;
(which latest Chrome, Safari, and Edge don't support anyway)
...and adjusts all text runs to start with 'p' -- which has special rendering
in Ahem -- so that directionality can still be inferred.
MozReview-Commit-ID: KBCsW0wjON7
--HG--
extra : rebase_source : d75bb1f1feb40cfe3541cbd3fe6694c63d71cd46
Update sccache build description to use the latest stable
rust toolchain. We didn't upgrade earlier because of problems
on Windows.
Note that we can't just depend on the stable rust toolchain
alias, because the toolchain deps are resolved in a single
pass. Instead, we use the current stable version explicitly.
MozReview-Commit-ID: 4OVbFsYZZLZ
--HG--
extra : rebase_source : 5b65d05f646f061a4018e0fad2e31e48e884912a
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
When the window is destroyed in unload event callbacks for the previous
document, we haven't started loading, i.e. we haven't called BlockOnload()
for the new document in nsContentSink::WillBuildModelImpl, so if we called
nsDocument::StopDocumentLoad() in such cases, UnblockOnload calls will mismatch
BlockOnload calls.
MozReview-Commit-ID: HjLtmGGvXKS
--HG--
extra : rebase_source : 8d81afd5cd7988cb165d9fee5dcfbf5fbf702331
The meaning of "possibly-changed" is provided by the big comment above
MustSendToContentProcesses.
On a new profile this reduces the number of prefs sent like so:
- Command-line: 222 --> 3
- IPC: 3129 --> 130
On an older profile:
- Command-line: 222 --> 3
- IPC: 3165 --> 180
MozReview-Commit-ID: DcgedhXhZd8
--HG--
extra : rebase_source : acef424fab5031347cbcbd5c3e6a24ee66895ef9
