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
This fixes a regression from bug 1454640 where urls had an extra 'docs' path inserted into them, e.g:
toolkit/components/telemetry/telemetry/index.html
became:
toolkit/components/telemetry/docs/telemetry/index.html
Differential Revision: https://phabricator.services.mozilla.com/D2079
--HG--
extra : histedit_source : 15c679e2f9366c1ea424adc4c82d7c184d80b3bb
