There are some unfortunate aspects of openWindow() and openWindow2() that make
this difficult. Namely, they sometimes return top-level chrome windows, and
sometimes a single content window from the top-level chrome window that they
open, depending on how they're called.
There really isn't any reason to return a BrowsingContext rather than a chrome
window in the former case, but there also really isn't a way to make the API
polymorphic in a way that would allow handling the two cases differently. So
at some point, the two cases should ideally be split into separate APIs rather
than separate special cases of a single API.
In the mean time, I've left openWindow() returning local mozIDOMWindowProxy
objects, since it isn't used by the DOM window.open() or openDialog() APIs,
and only updated openWindow2(). As a follow-up, we should remove both
openWindow() and openWindow2(), and replace them with openChromeWindow() and
openContentWindow() (or similar) methods which make it immediately clear what
type of window is being returned.
Differential Revision: https://phabricator.services.mozilla.com/D35689
--HG--
extra : moz-landing-system : lando
This is the first step in making it possible to return remote WindowProxy
objects from window.open() and related APIs.
This patch also incidentally fixes a bug where getContentWindowOrOpenURI
returned the top-level browser window rather than the new content window when
passed OPEN_NEWWINDOW for the `aWhere` parameter. This was not the expected
behavior, and was a potentially major footgun for any new users who expected
to always get the content window for the URL they were loading, rather than
sometimes getting a chrome browser window instead.
For now, that case just returns null, which is only a minor footgun, rather
than the major one we had before.
Differential Revision: https://phabricator.services.mozilla.com/D35688
--HG--
extra : moz-landing-system : lando
By default, the linker chooses a "generic" 32-bit CPU to optimize for,
and LLVM's "generic" 32-bit CPU model doesn't include some features that
are helpful for performance on microbenchmarks. We explicitly specify a
CPU model to ensure the model we want is selected.
On x86-64, we explicitly force a generically good processor model, even
though the automatically selected one didn't seem to hurt benchmarks.
Differential Revision: https://phabricator.services.mozilla.com/D40479
--HG--
extra : moz-landing-system : lando
It's a pity that Mach's conditions facility can't handle subcommands,
but it's a deep enough limitation that it's not worth addressing for
this patch.
Differential Revision: https://phabricator.services.mozilla.com/D39540
--HG--
extra : moz-landing-system : lando
API lint is arguably the most valuable lint of all, but it's also hard
to fit into the Phab ecosystem, since there's no place to hang the
"API hash not correct" message in the case when the hash hasn't been
updated at all. Therefore, this commit doesn't convert it. See also
https://github.com/mozilla-mobile/gradle-apilint/issues/61 for adding
file/line information to API lint.
Differential Revision: https://phabricator.services.mozilla.com/D35277
--HG--
rename : mobile/android/config/mozconfigs/android-api-16-frontend/nightly => mobile/android/config/mozconfigs/android-api-16/nightly-android-lints
extra : moz-landing-system : lando
This patch adds a global lint that only runs when a file or directory
that matches their configuration (via `extensions` and `exclude`) has
been modified or specified.
Global lints never shard into chunks; they are, by definition global
(i.e., across the entire source tree) and act on all inputs in a
single invocation. It's up to the global lint to manage command line
sizes, etc. Since batching is handled by the lint type but sharding
is handled by the lint roller, there's a little abstraction leak so
that the lint type can control how its invocation is sharded: the
existing `batch` member is generalized from the existing `True` and
`False` to add a new `"global"` value which disables sharding.
Differential Revision: https://phabricator.services.mozilla.com/D35275
--HG--
extra : moz-landing-system : lando
This allows lints to "condition" themselves on having a build
environment or a specific build application. It also adds the "name"
parameter, so that setup functions can be shared across lints.
`MozbuildObject` cannot be used as parameters to functions distributed
via multiprocessing, since they cannot be pickled (due, currently, to
internal terminal handles). Therefore we extract just a few key
parts of the environment to expose.
Differential Revision: https://phabricator.services.mozilla.com/D35274
--HG--
extra : moz-landing-system : lando
It's not worth accommodating all the ways to invoke commands from
Python, so expose the lock itself so that consumers can use
subprocess, Popen, etc as they choose.
Differential Revision: https://phabricator.services.mozilla.com/D35273
--HG--
extra : moz-landing-system : lando
This was Gradle-only and then !Gradle-only. Now Gradle is required
and this is unused.
Differential Revision: https://phabricator.services.mozilla.com/D31381
--HG--
extra : moz-landing-system : lando
When the RTP stats were refactored to match the specifications, the code that
displays them on about:webrtc was left unchanged. Update that code to reflect
the new stats types.
Differential Revision: https://phabricator.services.mozilla.com/D40458
--HG--
extra : moz-landing-system : lando
If the encoded frame is a keyframe, we should also mark the MediaRawData which would contain the data from this encoded frame as a keyframe.
Differential Revision: https://phabricator.services.mozilla.com/D40465
--HG--
extra : moz-landing-system : lando
As we are not going to modify the CodecSpecific, it should keep const when we forward it.
Differential Revision: https://phabricator.services.mozilla.com/D40464
--HG--
extra : moz-landing-system : lando
We don't have a contraint for using PlatformEncoderModule in the specific thread only, so we should use thread-safe refcounting for it, like PlatformDecoderModule.
Differential Revision: https://phabricator.services.mozilla.com/D40463
--HG--
extra : moz-landing-system : lando
The animations of motion path are not running on the compositor, and the
properties in [motion-1] is not part of transform-like properties (i.e.
nsCSSProperties::TransformLikeProperties()) for now, so we should run
transform animations on the main thread if offset-path is not `none`.
Differential Revision: https://phabricator.services.mozilla.com/D39966
--HG--
extra : moz-landing-system : lando
Not sure what you think of the `return aRv.Throw()` pattern, I find it nice, but
it seems we don't use it a lot.
Also Location.h is inconsistent on aError vs. aRv, if you want me to change to
one or the other let me know.
Differential Revision: https://phabricator.services.mozilla.com/D40450
--HG--
extra : moz-landing-system : lando
Also drive-by remove some useless prefixes since user-select was unprefixed in
bug 1492739.
Differential Revision: https://phabricator.services.mozilla.com/D40456
--HG--
extra : moz-landing-system : lando
This bug fixes up some minor issues in the raptor taskcluster configuration by removing the comm-central repository, adding a comment about requiring --full when run-on-projects is [], removing the run-on-projects entry for raptor-tp6-3-firefox, and moving the android/opt run-on-projects definition closer to the android/pgo definition in the defaults section.
Differential Revision: https://phabricator.services.mozilla.com/D40282
--HG--
extra : moz-landing-system : lando
This patch adds smart pointers to be used for initializing objects as C++11
"magic statics" -- that is, they are able to take advantage of C++11's
guarantee of thread safety during initialization by atomically constructing
both the smart pointer itself as well as the object being pointed to.
Unlike Static{Auto,Ref}Ptr, they have non-trivial constructors, though they
must still have trivial destructors to prevent emission of atexit calls.
The new classes use the new `MOZ_STATIC_LOCAL_CLASS` annotation which ensures
their instantiations are static locals and prevents non-trivial destructors.
Differential Revision: https://phabricator.services.mozilla.com/D40092
--HG--
rename : xpcom/base/StaticPtr.h => xpcom/base/StaticLocalPtr.h
extra : moz-landing-system : lando
All dependencies are fixed, or no longer reproducible. As such both
flags can be re-enabled. Also reftests won't have to specify the
exactly same flags on its own anymore.
Differential Revision: https://phabricator.services.mozilla.com/D40395
--HG--
extra : moz-landing-system : lando
This code was jumping through some hoops that seemed unnecessary. Given
History::Go(0) already calls Location::Reload(false), seems we can just handle
the new pref in one place, and also simplify the code a bit.
Differential Revision: https://phabricator.services.mozilla.com/D40431
--HG--
extra : moz-landing-system : lando
those unwrap_or are mostly seen during the batching, where we should asssume that
the primitives are not clipped out and just unwrap() accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D39940
--HG--
extra : moz-landing-system : lando
This removes all telemetry which expired in Firefox 69 or earlier, with the
exceptions of the following, which we plan to renew:
* AUDIO_TRACK_SILENCE_PROPORTION
* MEDIA_AUTOPLAY_WOULD_BE_ALLOWED_COUNT
* MEDIA_AUTOPLAY_WOULD_NOT_BE_ALLOWED_COUNT
* MEDIACACHESTREAM_LENGTH_KB
* MEDIA_MKV_CANPLAY_REQUESTED
* MEDIA_PAGE_COUNT
* MEDIA_PAGE_HAD_MEDIA_COUNT
* VIDEO_DROPPED_FRAMES_PROPORTION
* VIDEO_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME_PERCENTAGE
* VIDEO_INFERRED_DECODE_SUSPEND_PERCENTAGE
* VIDEO_INTER_KEYFRAME_AVERAGE_MS
* VIDEO_INTER_KEYFRAME_MAX_MS
* VIDEO_SUSPEND_RECOVERY_TIME_MS
* VIDEO_VP9_BENCHMARK_FPS
* WEB_AUDIO_BECOMES_AUDIBLE_TIME
* WEBVTT_TRACK_KINDS
Differential Revision: https://phabricator.services.mozilla.com/D37313
--HG--
extra : moz-landing-system : lando
