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
In order to support the WebXR implementation, VRDisplayState is being extended to enumerate the type of sessions a device supports (Inline, Immersive-VR, or Immersive-AR) and to report if the blend mode for AR would be additive or alpha blended).
Differential Revision: https://phabricator.services.mozilla.com/D39916
--HG--
extra : moz-landing-system : lando
"transport" is the old name for the field. This makes it so that the transport
protocol is no longer printed as "undefined" in the ICE candidate table.
Differential Revision: https://phabricator.services.mozilla.com/D39981
--HG--
extra : moz-landing-system : lando
- Don't import the build settings since the settings in gecko is more
complicated.
- Print out the picked commits when running the scripts
Differential Revision: https://phabricator.services.mozilla.com/D40097
--HG--
extra : moz-landing-system : lando
The AboutLoginsCreateLogin event was being used in two different contexts, one to signal to AboutLoginsChild.jsm that a new login was created and in a second context to signal within the page that the user wanted to start creating a new login. This overloading of the event has now been fixed. There was also another issue when comparing the typed origin to the saved origin which has been fixed. This patch also properly selects a different login in the list when the current one is deleted.
Differential Revision: https://phabricator.services.mozilla.com/D40130
--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
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
