This is necessary for changes to encoding constraints and simulcast encodings to
be picked up.
MozReview-Commit-ID: JpVN0ST70Cn
--HG--
extra : rebase_source : ea61544b98e7e231527cf6f13d78862d3567b4b7
<!-- Please describe your changes on the following line: -->
per https://github.com/servo/servo/pull/4297/files#r158729975
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: d41f720ee422f53a7c49d0877d105d8750ea404f
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 301ea2abc9fa41a80af1bc2590c108a2ffec8ccf
Calling SetSpec on an nsIURI object doesn't reinitialize the object, meaning
it's not equivalent with creating a new URI with the same spec. While this
might be counter-intuitive we want to preserve existing behaviour for
the moment.
This change makes BaseURIMutator::InitFromSpec call SetSpec on the existing
cloned URI if available. Otherwise it creates a new one.
MozReview-Commit-ID: LuHVRhBItiP
--HG--
extra : rebase_source : fc7b64d01adcb7f2ac5bbd9cfc16dadb3c4939c9
If the toolbox is open when a stylesheet is loaded, the network monitor should
have recorded the response content. When a tool asks for stylesheet text, try
asking the network monitor first before falling back to an extra fetch as a last
resort.
MozReview-Commit-ID: E2pQ04ARfQo
--HG--
extra : rebase_source : b10fb44e313ece5757961ca81a3bc0f76753ed8e
PAGE_SHOW, SITE_CLICKED expired in version 35 and can safely be removed.
LIFE_SPAN was triggering alerts because Activity Stream is the new
default about:newtab and data for it is no longer being collected.
MozReview-Commit-ID: 3TIG5jwRfDr
--HG--
extra : rebase_source : 22d915006c44244ecffac9ebc04876730090dd13
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
