We allow swapping frameloaders between unrelated documents, so we need to
reparent wrappers when the owner content changes.
MozReview-Commit-ID: LNIf4ZrCZLo
--HG--
extra : rebase_source : 8041d1601962d61e675e78e3447c7772eee89df0
XPConnect wrapper overhead for this interface has been showing up heavily in a
lot of my profiles, in some places accounting for 50ms of the 80ms we spend
getting getting <browser> messageManagers. This improves the situation
considerably.
MozReview-Commit-ID: 9d1hCORxsYG
--HG--
rename : dom/base/nsIFrameLoader.idl => dom/webidl/FrameLoader.webidl
extra : rebase_source : d8a1fc1a19632ba36a9fc6f63873f7534671a13b
The robustcheckout extension from revision
134574b64ddfa4d7c31977d792761cceca67665a of the version-control-tools
repo is vendored without modifications.
Changes since last time include printing of the Mercurial version and
more robust handling repositories not using modern storage
requirements.
This patch was not explicitly reviewed by glob. But glob reviewed all
the robustcheckout changes since the last vendor. So by the transitive
property of code review...
MozReview-Commit-ID: CejuVVGpaEy
--HG--
extra : rebase_source : d24dd19357c44f50f7605e974d91434bac3c47f8
extra : source : 68cdc2d1184dec80455ba0ea1ebbcab232b8c119
We use `hg init` to create the directory. Because this is what
typically occurs.
We also remove the disabling of "dotencode" in the hgrc. This was added
in https://hg.mozilla.org/build/mozharness/rev/b1dbc0f56ff8 (bug 857853)
for reasons that are unclear to me. We should never disable dotencode
because it may make some repositories not clonable on Windows
filesystems.
Disabling dotencode will also interfere with the latest version of
robustcheckout, which requires its presence.
MozReview-Commit-ID: 35qBsgwp0uW
--HG--
extra : rebase_source : b786fb38f6b09da9614ac40f5de8231b8305bf5d
We use Mercurial 4.3.1 pretty much everywhere in CI now.
Mozharness should be testing with it as well.
MozReview-Commit-ID: HT2rocEvdIe
--HG--
extra : rebase_source : 148a9cd82b18e693ee570f31fc961373e8466a3c
This will allow tracking whether there have been only additions to the
stylesheet set, and in that case don't destroy and completely rebuild the
invalidation map.
This is on top of #18143.
Source-Repo: https://github.com/servo/servo
Source-Revision: 019b125963d4db9b18991d3ab06042e475c83f9f
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 157b6d9f35c310668763e09e94479d9a60eb17f9
The GCC plugin used for hazard builds was built for GCC 4.9. Until a new
plugin is built by a toolchain job for the "default" version of GCC we
build Firefox with, the builds using the plugin need to stay with the
version the plugin was built for.
Some xpcshell tests run with _windowless_ browser and calls its LoadURI().
It then failed to get `aBrowser.contentWindow` when we tried to create OA
and detected if the browser was in the private mode.
MozReview-Commit-ID: DWGMyfao1wG
--HG--
extra : rebase_source : c8ed703221aa84ead8288dc7c1f200838808792b
The triggeringPrincipal needs to be consistent with the given userContextId.
MozReview-Commit-ID: Ao4hokoIcLb
--HG--
extra : rebase_source : b342a8020960e7e1028c0230ebfc0daf41c60d43
In chrome process, we often know which url is going to be loaded.
As a performance optimization, we can start initiating network
connection before sending out the 'LoadURI' message to the content
process.
MozReview-Commit-ID: L79ylHOaxX8
--HG--
extra : rebase_source : cc3aeefedde21dc8eaaf37c67710980b0204f4dc
The bug is caused by the first call to ResizeReflow in
nsDocumentViewer::GetContentSizeInternal, which reflows the content with
unlimited height. ResizeReflow calls DidDoReflow, which calls a
callback installed by nsHTMLScrollFrame that clamps the scroll port setting
the scroll top to 0 and losing the original scroll top. When the content
is reflowed again to the maximum height, the scroll top stays at 0.
MozReview-Commit-ID: 3VkgWLqSTDP
--HG--
extra : rebase_source : 68c65746e014f0702de82ea576897592b07f81cb
