I botched another patch in this series because I was confused about when zero
meant "no limit" and when it actually just meant zero, so I figured I'd fix this.
MozReview-Commit-ID: 5vgzKGSKL8F
--HG--
extra : rebase_source : dc57c22b08455a1867eeaa139b3045d2ae181cef
extra : histedit_source : e82898f74e8568bbbd10f7589427f5fbbcfe24fa
* Code in XMLHttpRequestMainThread is converted to set the username and password individually. This is because when the parameters are empty, it ended up calling SetUserPass(":") which always returns an error.
MozReview-Commit-ID: 3cK5HeyzjFE
--HG--
extra : rebase_source : f34400c11245d88648b0ae9c196637628afa9517
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
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
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.
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
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
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
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
Fairly straightforward. Fixes the tests that were broken due to
the changes introduced in part 1.
MozReview-Commit-ID: GbZ9ZpmG9nE
--HG--
extra : rebase_source : ebb2088288718631a941139d5a4d945259aaa0c6