This patch completely disables *ccov, and *jsdcov builds and tests when scheduling them through try option syntax as these build variations use a lot of resources and are rarely needed to be scheduled. The only way to schedule code coverage from now on will be with the |mach try fuzzy| tool.
Differential Revision: https://phabricator.services.mozilla.com/D3921
--HG--
extra : moz-landing-system : lando
The sidebar regressed at some point and wasn't showing
a scrollbar when it was needed. This patch fixes that
by making the sidebar overflow and adds a test to make
sure we don't regress.
Differential Revision: https://phabricator.services.mozilla.com/D3976
--HG--
extra : moz-landing-system : lando
After analyzing test_request.html it became clear that it relied on two false
assumptions:
1. It assumed that a service worker is notified that it's being installed before
any client can interact with it.
2. It assumed that a service worker will always be installed upon registration,
if it was unregistered before.
The first assumption is not backed by the spec; it seems that the opposite behavior
is the correct one (https://github.com/w3c/ServiceWorker/issues/1347). The second
assumption ignores the possibility of resurrection, where a service worker is re-
registered before getting uninstalled.
This commit addresses both problems by not relying on the installation phase,
instead passing the script URL as a search parameter and loading it at service
worker script evaluation time. It then runs the test function in response to a
message from the client.
Differential Revision: https://phabricator.services.mozilla.com/D3879
--HG--
extra : moz-landing-system : lando
When building binaries for Linux/aarch64, ./mach configure cannot generate
Makefile by the following error. So we need Linux/aarch64's gn-configs.
1:07.80 mozbuild.frontend.reader.SandboxValidationError:
1:07.80 ==============================
1:07.80 FATAL ERROR PROCESSING MOZBUILD FILE
1:07.80 ==============================
1:07.80 The error occurred while processing the following file or one of the files it includes:
1:07.80 /hg/mozilla-central/media/webrtc/trunk/webrtc/common_audio/common_audio_c_gn/moz.build
1:07.80 The error occurred when validating the result of the execution. The reported error is:
1:07.80 Source file should only be added to UNIFIED_SOURCES once: /media/webrtc/trunk/webrtc/common_audio/signal_processing/complex_bit_reverse.c
Differential Revision: https://phabricator.services.mozilla.com/D3607
--HG--
extra : moz-landing-system : lando
When you enter JS into the console, we can now syntax highlight it in
the output when CodeMirror is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D3842
--HG--
extra : moz-landing-system : lando
Since we don't block media without audio track anymore, the original telemetry scalar becomes useless.
We need to change its meaning in order to know the number of allowed autoplay without audio track.
Differential Revision: https://phabricator.services.mozilla.com/D3673
--HG--
extra : moz-landing-system : lando
Add two telemetry scarlar,
"MEDIA_BLOCKED_NO_METADATA" records how many media which was blocked because it hadn't loaded metadata yet.
"MEDIA_BLOCKED_NO_METADATA_ENDUP_NO_AUDIO_TRACK" records how many media which was blocked because it hadn't loaded metadata and ended up for being no audio track.
By collecting those data, we can know the proportion of media which should be autoplay but was blocked because of lacking metadata.
Differential Revision: https://phabricator.services.mozilla.com/D3671
--HG--
extra : moz-landing-system : lando
We would allow media without audio track to autoplay after it had loaded the metadata.
If media hasn't loaded metadata yet, we would treat it as audible media and then block it.
Differential Revision: https://phabricator.services.mozilla.com/D3670
--HG--
extra : moz-landing-system : lando
...down. The remedy to prevent the crash is to exit the loop when the
mShutdown flag is set. This does not attempt to address the underlying cause
of why the request continues to be pending, although this is also a concern.
Files changed:
netwerk/base/ProxyAutoConfig.cpp - expanded lambda containing logic of when
to stop waiting for the request to complete to include a check to the mShutdown
flag. Also logged a warning if the loop is exited because of mShutdown.
Differential Revision: https://phabricator.services.mozilla.com/D3977
--HG--
extra : moz-landing-system : lando
Bug 1470910 broke the positioning because it changed the tag name of .urlbar-input-box but didn't update the related rule in browser.css, and then bug 1480355 landed and made it worse. This patch fixes the first problem by updating the tag name in the CSS, and it fixes the second problem (and bug 1480355) by setting `direction: ltr` on .urlbar-input-box.
Differential Revision: https://phabricator.services.mozilla.com/D4015
--HG--
extra : moz-landing-system : lando
The XUL elements were not being created because of the wrong createElement
call.
MozReview-Commit-ID: 54RqUJQAqHq
Differential Revision: https://phabricator.services.mozilla.com/D3998
--HG--
extra : moz-landing-system : lando
Before this patch -- with the nsCString return type -- we have to do heap
allocation and copying to produce the return value. But the callers don't
actually care about having a nsCString -- they just call .get() to access the
character buffer, and log it, and then they're done. They can do this just as
easily with the stack-allocated nsAutoCString that PartialHashHex() works with
locally, so let's change the return type so that Return Value Optimization
can give them that variable directly and avoid needless copying/allocation.
This patch addresses the following clang 8.0 build warning:
LookupCache.h:63:12 [-Wreturn-std-move]
local variable 'hex' will be copied despite being returned by name
Differential Revision: https://phabricator.services.mozilla.com/D3920
--HG--
extra : moz-landing-system : lando
The fragment is also used to handle intents launched through GeckoAppShell.
openUriExternal(), such as e.g. when launching downloaded files from
about:downloads.
The synchronous code path when not in private browsing is already covered by the
code added in bug 1450449, but the async path through the fragment when in
private browsing needs to be handled separately.
Differential Revision: https://phabricator.services.mozilla.com/D3916
--HG--
extra : moz-landing-system : lando
Getting a working local build with the system clang might be tricky, while
building with NDK r17 clang is broken (bug 1484723).
NDK r18-beta1 fixes this, but also made all jvalue* method parameters in jni.h
const,so in order to support building with it we need to adjust our relevant
function types, too.
Differential Revision: https://phabricator.services.mozilla.com/D3832
--HG--
extra : moz-landing-system : lando
