Since we've decoupled the writing of the StartupCache from the freeing
of the StartupCache's tables (which takes nontrivial time), this patch
moves the StartupCache's destructor later in shutdown so it will be
skipped in the early _exit(0) efforts. There is a remaining
WaitOnWriteThread in the StartupCache's destructor, but this is a
minor sanity check to avoid use-after-frees in the write thread during
shutdown. In general it won't matter as we already wait for the write
thread in the xpcom-shutdown observer, and if we shut down during write,
the system is set up to be okay with that (because it already happens).
Differential Revision: https://phabricator.services.mozilla.com/D62295
--HG--
extra : source : d79f1d283acde1a971fe0e5e6f1a8db075f8589a
extra : histedit_source : 32a2b4fec1fcf35960155b0f4280a38bcb54ec19
The initial thought for getting the StartupCache out of the shutdown
path was to simply not write it during shutdown, as it should write
60 seconds after startup, and the theory was that if the user shut
down within the first 60 seconds of use, they were likely updating or
something and it shouldn't matter. However, considering how many of
our users only ever open one tab, I think it's rather likely that
users are starting up firefox to go to a web site, then closing it
when done with that website, and then maybe opening up a new instance
in order to go to a different website. Accordingly it still makes
sense to continue writing it. However, we may as well leverage a
background thread for this and get it kicked off earlier during
shutdown, so we don't sit there blocking in the destructor late
during shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D62294
--HG--
extra : source : 7b7b147b6955cee07e0c115993446bfbd59cf7e2
extra : histedit_source : 6990122d6b1ac4939b0e4b0a5e452183fb981e19
Currently the sections regarding mma events and deeplinks are not properly
formatted making the text hard to read, follow and understand.
Use the `.. code-block:: json` formatting for Events. Found this in the history
for the previous documentation from central
Add a newline before the deep links bullet list so that each element would be
properly formatted.
Before and after screenshots of the docs are posted in the ticket.
Depends on D62730
Differential Revision: https://phabricator.services.mozilla.com/D62731
--HG--
extra : moz-landing-system : lando
Pick commits:
- 7fe03b4: Bail out if the output device has no output channel (#50)
- ad74bad: Update README
- 3f38b17: Replace `*.get_mut()` by `*.store()` on all the `Atomic*` (#47)
- b1bc781: Run tests by sanitizers (#46)
Differential Revision: https://phabricator.services.mozilla.com/D62654
--HG--
extra : moz-landing-system : lando
The 'getter button' wasn't working correctly on root level items in the preview popup.
A check is added on root item to see if it has any corresponding evaluation result,
and if so take that value instead of the original one.
A test is added to ensure that the button now works on those top-level elements in
the preview popup.
Differential Revision: https://phabricator.services.mozilla.com/D61086
--HG--
extra : moz-landing-system : lando
Doing this helps ensuring that all async work done in panels,
when attaching to the top level target, to fetch already existing resources,
is fully completed before the test ends.
Differential Revision: https://phabricator.services.mozilla.com/D62554
--HG--
extra : moz-landing-system : lando
Combine AllocKind::SCRIPT and AllocKind::LAZY_SCRIPT arenas. This impacts
code that scans the arenas directly but required checks were added in a
previous patch.
This removes background finalization of those LazyScript types.
Depends on D62687
Differential Revision: https://phabricator.services.mozilla.com/D62688
--HG--
extra : moz-landing-system : lando
To prepare for merging the LazyScript and JSScript gc-arenas we need to fix
uses of cellIter. This patch adds checks for the BaseScript::isLazyScript
flag. Variable names are also cleaned up to be more consistent.
Note semantics are unchanged and these continues are not currently executed
(as confirmed by making them MOZ_CRASH).
This patch does the naive thing in each case for ease of review. Future
patches will simplify code where possible in order to tolerate a mix of lazy
and non-lazy scripts.
Depends on D62686
Differential Revision: https://phabricator.services.mozilla.com/D62687
--HG--
extra : moz-landing-system : lando
The ZoneCellIter will already check for finalization so we don't need to
worry about checking again.
Depends on D62681
Differential Revision: https://phabricator.services.mozilla.com/D62686
--HG--
extra : moz-landing-system : lando
Now that JSScript and LazyScript share a trace method, we can use a single
TraceKind within the GC. To acheive this we also must remove eager marking of
LazyScripts.
Differential Revision: https://phabricator.services.mozilla.com/D62681
--HG--
extra : moz-landing-system : lando
This patch creates a union field in BaseScript to hold either form of
pointer. An IsLazyScript flag is added to ImmutableFlags to know which union
arm to trace. We are also able to use a single trace function for both.
IsLazyScript flag to disambiguate the union arms.
Note that this field will be removed entirely once the JSScript and
LazyScript instances are merged.
Differential Revision: https://phabricator.services.mozilla.com/D62680
--HG--
extra : moz-landing-system : lando
Generalize the code to handle BaseScript types to prepare for eliminating
TraceKind::LazyScript. Also remove JSScript::sizeOfData method in favour of
the equivalent BaseScript::sizeOfExcludingThis.
Differential Revision: https://phabricator.services.mozilla.com/D62679
--HG--
extra : moz-landing-system : lando
clang-plugin.dll links against clang.exe so they both need to use the same C++ standard. This is achieved by having build/clang-plugin/moz.build use the flags from llvm-config. However, llvm-config uses the `-std:c++14` format, so our flags end up looking like:
`-Xclang -std=c++17 ... -std:c++14`
and apparently the former wins out in clang's option plumbing, so the compiler still thinks we requested c++17.
This patch makes clang-plugin use the `-Xclang -std=` format so that the override happens as desired.
Differential Revision: https://phabricator.services.mozilla.com/D62271
--HG--
extra : moz-landing-system : lando
Currently, the GNU version of basename from string.h is used, which
has behavior that conflicts with the POSIX version in libgen.h.
The GNU basename is not available in all libcs. In particular, it
is missing in musl libc, causing a build failure:
error: 'basename' was not declared in this scope
The GNU version has the following implementation:
char *p = strrchr (filename, '/');
return p ? p + 1 : (char *) filename;
The POSIX version has slightly different semantics. It may modify
its argument string, or copy part of it to static storage. However,
it will also delete trailing slashes, while the GNU version will
return the empty string if there is a trailing slash.
This change resolves the issue by including libgen.h, adopting POSIX
basename semantics. This should be a safe change for the following
reasons:
- The google-breakpad code, from which this code was derived, has
also switched to the POSIX basename:
072f86ca83%5E%21/#F4
- The version of LulElf.cpp in mozglue/baseprofiler has also switched
to the POSIX basename:
https://hg.mozilla.org/mozilla-central/annotate/de1c3ae8df14cdb2c94a817b02dcffcb2cee12e2/mozglue/baseprofiler/lul/LulElf.cpp#l54
- The BaseFileName function is called only with paths to ELF files,
never directories, so the paths will never contain a trailing
slash, and the two versions of basename will behave identically.
Differential Revision: https://phabricator.services.mozilla.com/D61047
--HG--
extra : moz-landing-system : lando
This change adds new "remote backbuffer" logic when compositing without
HW acceleration on Windows (IE compositing through Cairo using the Win32
GDI)
A new piece of shared memory is created between the GPU process and the UI
process, and the GPU process sends requests to the UI process to first "borrow"
a properly-sized buffer to draw into, and then sends a "present" request to
tell the UI process to actually blit the buffer to the Win32 window.
This is needed for the GPU sandbox to work, since Windows rightly doesn't
allow the untrusted GPU process to directly draw the contents of a window
owned by the trusted UI process.
Differential Revision: https://phabricator.services.mozilla.com/D61370
--HG--
extra : moz-landing-system : lando
Remove some dependencies on JSRuntime by storing flags on the Zone to indicate whether a zone is the atoms zone or the self hosting zone.
Differential Revision: https://phabricator.services.mozilla.com/D62620
--HG--
extra : moz-landing-system : lando
Getting the JNI calls here to work requires a good amount of webrtc.org
machinery. It might be worth setting that up the next time we do an upstream
merge, but for now, it is a lot simpler to just remove the affected code,
given that we are not interested in collecting this data anyway.
Differential Revision: https://phabricator.services.mozilla.com/D61860
--HG--
extra : moz-landing-system : lando
Although originally part of webrtc.org, this code has subsequently been
removed by upstream. Moving it to under dom/media should make it clearer that
this is code that we are maintaining and simplify future upstream merges.
Differential Revision: https://phabricator.services.mozilla.com/D61850
--HG--
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/device_info_android.cc => dom/media/systemservices/android_video_capture/device_info_android.cc
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/device_info_android.h => dom/media/systemservices/android_video_capture/device_info_android.h
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/java/src/org/webrtc/videoengine/CaptureCapabilityAndroid.java => dom/media/systemservices/android_video_capture/java/src/org/webrtc/videoengine/CaptureCapabilityAndroid.java
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/java/src/org/webrtc/videoengine/VideoCaptureAndroid.java => dom/media/systemservices/android_video_capture/java/src/org/webrtc/videoengine/VideoCaptureAndroid.java
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/java/src/org/webrtc/videoengine/VideoCaptureDeviceInfoAndroid.java => dom/media/systemservices/android_video_capture/java/src/org/webrtc/videoengine/VideoCaptureDeviceInfoAndroid.java
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/video_capture_android.cc => dom/media/systemservices/android_video_capture/video_capture_android.cc
rename : media/webrtc/trunk/webrtc/modules/video_capture/android/video_capture_android.h => dom/media/systemservices/android_video_capture/video_capture_android.h
extra : moz-landing-system : lando
This is an import of the Android camera code as of upstream revision
26762d0425ffd15af9ddc3ae669373668827ea00 (Dec 20, 2019). This takes just the
files required to build the camera related classes.
Differential Revision: https://phabricator.services.mozilla.com/D61849
--HG--
extra : moz-landing-system : lando
These tests are all timing out in Firefox because we don't send either
a load or an error event for CSP-blocked loads. To work around this,
poll the iframe for the load, assuming it's complete when we see a
non-about:blank document with readyState complete (or an exception
from trying to access a cross-origin resource).
Differential Revision: https://phabricator.services.mozilla.com/D62447
--HG--
extra : moz-landing-system : lando
Doug Thayer
Hamzah
Jared Wein
Petru Lingurar
Chun-Min Chang
Tuan
Eden Chuang
Stepan Stava
Dão Gottwald
Jason Laster
Julian
Alexandre Poirot
Christian Holler
Simon Giesecke
Ted Campbell
David Major
Samuel Holland
Chris Martin
Markus Stange
Julien Cristau
Mark Banner
Jon Coppeard
James Graham
Dan Minor
Mirko Brodesser
Csoregi Natalia