Clean up after gecko [bug 1421358](https://bugzilla.mozilla.org/show_bug.cgi?id=1421358), which removed the pref entirely.
Source-Repo: https://github.com/servo/servo
Source-Revision: 02f1864770c108a47b3c83c3d89293222cb6dfcf
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2588bb21f54258c3639ad1d6a222f98fcef0761d
Implement new processPings and _sendPing, handle sessions via registerNewOnboardingSession
This patch covers all new events except onboarding-noshow-smallscreen and overlay-disapear-resize events will be implemented in bug 1417769
MozReview-Commit-ID: 3jNAmOcrvEa
--HG--
extra : rebase_source : 58f1deea02ff6a07c25a0dce1c291ca1ecfa17e8
Capabilities are currently sent to the content frame script when
its IPC message listeners attach (on Marionette:ListenersAttached).
If for whatever reason a capability's value changes since the script
was registered, for example by a user calling the WebDriver:SetTimeouts
command, a race condition is introduced where the capabilities in
chrome will differ from those cached in the frame script.
To remove any chance of race conditions, this patch changes the
content frame script to query the capabilities from chrome every time
it needs them. This is slightly less efficient, but should be neglible.
The patch also clears up some unused state, such as the
curBrowser.newSessionCommandId property, which did not appear to
be used for anything interesting.
MozReview-Commit-ID: 1bSrRu5nK3h
--HG--
extra : rebase_source : 06f6fb8e4a6d04e5c4fa56d1becafd55ed0d1dee
This patch adds a few console.count stubs and check
that they all render as expected.
MozReview-Commit-ID: IejxMKnLTAz
--HG--
extra : rebase_source : a9df8bd9eb1b78c6f05106c16d48dd31d16087f6
We're still somewhat undecided on how to exactly handle external intents
arriving while the tabs tray is open, however in the case of Assist App intents
- opening a new tab in editing mode while the tabs tray remains open causes some
weird behaviour (the keyboard appears in front of the tabs tray and no matter
which tab is selected on the tabs tray, you first enter editing mode and then
always end up in the tab opened by the Assist App intent)
- the goal of our Assist App intent handling is to allow the user to enter a
search query or an address into the URL bar
hence we should hide the tabs tray (if open) when handling such an intent.
MozReview-Commit-ID: GpwrscdNjZP
--HG--
extra : rebase_source : 5275a8323a0ca5bcebdc6fe2148a8de4b87a7651
The test was failing because we have more than one
networkUpdate in the store.
As it's not the purpose of this test case to assert the
number of updates, let's just check that we have some,
and that they are removed after MESSAGES_CLEAR.
MozReview-Commit-ID: FgZv8epfP0q
--HG--
extra : rebase_source : 269f8654fa0f9f06c8ece5fe6415f82385553e85
The tests were failing because all the sidebarToggle actions
were renamed to sideBarClose, which made the tests inacurate.
MozReview-Commit-ID: LBkqTzNhaqV
--HG--
extra : rebase_source : 5943924d6fb073cb2375df275665de206aaf857b
Part of this is a backout of bug 1421054 which is no longer needed now
that we can assume equivalent clip items have identical pointer values.
MozReview-Commit-ID: BhnLVmVr4TX
--HG--
extra : rebase_source : b9bbb733fc69a0f15cd35d0265589aea257a5285
See the documentation in the added function for details.
MozReview-Commit-ID: 4R0WaSy0tm2
--HG--
extra : rebase_source : f6bcdafb708f9527afafab54e3ba7e34040054b0
When a clip is defined in WebRender, any transforms on the containing
stacking contexts are baked into the clip's position. Therefore, trying
to use a clip that was defined inside a transformed stacking context in
other parts of the WR display list doesn't work properly. This was a
latent bug in ScrollingLayersHelper that was previously not exposed
because in these cases Gecko itself creates separate
DisplayItemClipChain items. Now that we are going to deduplicate those
DisplayItemClipChain items, it exposes this latent bug which we need to
fix.
MozReview-Commit-ID: Icd7L1JuY8s
--HG--
extra : rebase_source : 08749125b68b537244a054d00a41f671670d00bb
The system binutils and gcc are built with that option on Debian, but
not on CentOS. That makes no practical difference, except for the fact
that when building GCC, we use our own-built binutils (as per bug
1427316), but use the system GCC. And a GCC built with --with-sysroot=/
doesn't work with a binutils built without. However, a GCC built without
--with-sysroot=/ works fine with a binutils built with it. So this
change is compatible with building our GCC on both CentOS and Debian.
