One of the big downsides to |mach try fuzzy| is that if you use the interactive
finder, there's no way to repeat your last action. If you want to run the same
push again, you have to manually re-select all the same tasks a second time.
It is possible to save presets, but this is fairly heavy-weight and (more)
permanent. Sometimes you just want to re-run a push a few times and forget
about it. It's also possible to craft the query on the command line with -q,
but then you don't get the immediate visual feedback, so you can't be sure that
you typed out the right things without actually pushing.
With |mach try again|, everytime you generate a try_task_config.json via
'fuzzy', 'empty' or any other subcommands that may exist in the future, it'll
get stored in a history file under ~/.mozbuild. Then running |mach try again|
will simply re-run the most recent try_task_config.json.
You'll also be able to view the whole history via |mach try again --list| and
select a specific try_task_config.json (i.e not the most recent one) via
|mach try again --index <index>|.
Example usage will be:
$ ./mach try fuzzy
<select a bunch of tasks>
$ ./mach try again
<re-pushes exact same set of tasks>
MozReview-Commit-ID: 3EZjVCy08uq
Depends on D1808.
Differential Revision: https://phabricator.services.mozilla.com/D1867
--HG--
extra : moz-landing-system : lando
Both for mochitest (simply an expectation adjustment), and in mochitest (align
with the code).
MozReview-Commit-ID: 2UIq4zrcd02
--HG--
extra : rebase_source : 1858e73b3ad89aade3219ee8556c653c55c85bed
This test was testing that files are loaded/executed/etc in the page, but
what we really care about is that the webrequest api works. Other tests
are responsible for stuff like css and js actually work. The patch does
maintain (fixed) the js test, but removes the css test for lack of a good
way to properly wait for css to apply.
MozReview-Commit-ID: B2uByaxNeK2
--HG--
extra : rebase_source : 6779116f9f1a4a7ce24cd32c3648d1027343db93
a35b188d0e44 inadvertently regressed behavior in the case where
the Git status.showUntrackedFiles config option was set and
we want to purge untracked files.
Differential Revision: https://phabricator.services.mozilla.com/D2141
--HG--
extra : moz-landing-system : lando
The problem stemmed from having the DatePicker inside a ScrollView which
was receiving the swipe events.
To avoid this I've created the new FocusableDatePicker which has the ability
to prevent it's parent from receiving touch events.
MozReview-Commit-ID: 6VntjE5A0ec
--HG--
extra : rebase_source : a0f9589bf000ba10e5429347fe1dc7516e8eef3f
This patch addresses an issue with Firefox's proxy detection on networks which
do not have their a proxy auto-configuration (PAC) file hosted at
http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting
the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/
for an introduction to the protocol.
Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just
looked for a PAC file at http://wpad/wpad.dat
This patch only addresses the issue for Firefox on Windows, although it defines a
DHCP client interface which could be implemented on other platforms.
The high-level components of this patch are:
* nsIDHCPClient.idl - this is an interface which has been defined for querying the
DHCP server.
* nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of
http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy
thread. The class ExecutePACThreadAction has been augmented to include an
instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class,
'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC
file) back to the nsPACMan object.
* nsProtocolProxyService.cpp
Minor changes to reflect the fact that the PAC URL not being set does not always
mean there is no PAC to be used; instead it could be in the process of being
detected.
* TestPACMan.cpp
This is a new file, and tests only the DHCP auto-detect functionality.
Some tests use multiple threads, as they test the non-blocking proxy detection.
* DHCPUtils.cpp
A class containing the main logic for querying DHCP.
* WindowsNetworkFunctionsWrapper.cpp
A very thin wrapper around the Windows API calls needed by DHCPUtils.
This class was introduced so it could be mocked out in tests.
* nsWindowsDHCPClient.cpp
* An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin:
most logic is implemented in DHCPUtils.
* TestDHCPUtils.cpp
Tests for DHCPUtils and nsWindowsDHCPClient
MozReview-Commit-ID: 4xFQz3tOLEx
--HG--
extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
Right now, the firstPartyDomain won't be set when using IP addresses as
first party domains. It is because of that the TLD service won't accept
IP addresses as valid hosts. The patch fixes this problem by detecting
that if the host is a IP address. If it is, we will still set the
firstPartyDoamin with the IP address.
Differential Revision: https://phabricator.services.mozilla.com/D1977
--HG--
extra : moz-landing-system : lando
Such messages happen intermittently on Android, presumably from bfcache being
purged due to memory pressure (which would then cause the back() operation
behave like a fresh load). So on Android, we'll now treat these redundant
messages as a "todo()" failure, to indicate that something went wrong but avoid
turning the testsuite orange.
MozReview-Commit-ID: GkaxB06vL7q
--HG--
extra : rebase_source : 64c0c0a41452d573062774b2300a26aad179b309
Before this patch, there is a race condition that the refresh driver updates
the most recent refresh time but animations corresponding to the refresh driver
don't update their internal state, that causes the inconsistency that such
animations are regarded as finished on the most recent time whereas their
internal states represent the animations are still in active. This is the one
of the cause of bug 1466010, i.e. the display item corresponding to the
animation is going to be rebuilt without calling MarkNeedsDisplayItemRebuild.
MozReview-Commit-ID: 9adzDV9E3ka
--HG--
extra : rebase_source : 7120e9f462309d1c4efe995ef64aeead9e29ff8f
This patch adds a new IPDL protocol PBackgroundLocalStorageCache. It is used by LocalStorageCache object to broadcast changes in local storage cache to other content processes. Each origin has its own PBackgroundLocalStorageCache, so now we can notify content processes that actually have a local storage cache for given origin. This greatly improves performance and reduces memory footprint especialy when local storage changes carry big strings and/or happen very quickly (before this patch all child processes were blindly notified).
We can start playing while we're awaiting a response to an autoplay-media
permission prompt, for example if the user clicks on a play button. In such
cases, it doesn't make sense to keep the autoplay permission request promise
connected in HTMLMediaElement, as since we're playing we'll be resolving the
play() promises and thus we won't be taking action on the autoplay request
promise's result. So we should just disconnect the autoplay permission request
promise if it's connected when we start playing.
MozReview-Commit-ID: 1aiCLXV7Ja9
--HG--
extra : rebase_source : c439e8f084ac8cc01db578d712e15d3174a08e71
Updated rsdparsa to 75d5c6df6728fbab502db06940062e0358536f9f from github
upstream
MozReview-Commit-ID: 9hr7DV6KTkK
--HG--
extra : rebase_source : c5b2c003e76489e267390402ebb5947cf3ec48b6
Simon Fraser
Andrew Halberstadt
Paul Adenot
Francesco Lodolo (:flod)
Shane Caraveo
Tim Nguyen
Margareta Eliza Balazs
Gregory Szorc
Xidorn Quan
Brindusan Cristian
Petru Lingurar
Polly Shaw
Abdoulaye O. Ly
Julian Descottes
Raphael Pierzina
Razvan Caliman
shindli
Tim Huang
Daniel Holbert
David Major
arthur.iakab
Ryan VanderMeulen
Andreea Pavel
Hiroyuki Ikezoe
Ciure Andrei
Csoregi Natalia
Kris Maglione
Jean-Yves Avenard
Jan Varga
Olli Pettay
Chris Pearce
Andi-Bogdan Postelnicu
Emilio Cobos Álvarez
Nils Ohlmeier [:drno]
Matt Woodrow