For some reason this causes some sort of failure in the doc upload
process. No other mach_commands.py files do this so this patch moves
the import into the functions that use it, which bypasses the problem.
Differential Revision: https://phabricator.services.mozilla.com/D36333
--HG--
extra : moz-landing-system : lando
The nursery isn't exactly swept, but it is evicted. Name this function to
make it match its context better.
Differential Revision: https://phabricator.services.mozilla.com/D36316
--HG--
extra : moz-landing-system : lando
HandleDebugTrap calls DebugAfterYield, which can call the onEnterFrame debugger hook.
This hook can mess with debugger state so HandleDebugTrap needs to be a bit more
careful with its assertions.
Differential Revision: https://phabricator.services.mozilla.com/D36209
--HG--
extra : moz-landing-system : lando
We want dweb URLs to continue working as before bug 1536744 landed.
So we make sure to instantiate it as an nsStandardURL.
This is not a good long-term solution, as we don't want to hardcode
all the various schemes that we want to behave properly.
The fix would be to add a new spec-compliant nsIURI implementation,
based on RustURL and use it for all unknown schemes.
See bug 1561860 for a more complete solution.
Differential Revision: https://phabricator.services.mozilla.com/D36168
--HG--
extra : moz-landing-system : lando
This patch adds idle browser (*-idle-bg)tests to Raptor which have the app running on about:blank in the background for 20 minutes. It adds the 'background_test' flag to 'scenario' type Raptor tests to make a test run in the background. Furthermore, a unit test is added to the Raptor control server tests as well as methods to check if the app was properly backgrounded or foregrounded.
Differential Revision: https://phabricator.services.mozilla.com/D32428
--HG--
extra : moz-landing-system : lando
The conversion for "regular" <tabs> elements is straightforward, most of
the work here is to support the tab strip (the <tabs> element with the id
"tabbrowser-tabs"). The markup needed for the tab strip moves directly
into browser.xhtml and the construction/teardown logic is now explicitly
driven from gBrowser. There are many more little tweaks too numerous to
enumerate.
Differential Revision: https://phabricator.services.mozilla.com/D32855
--HG--
rename : browser/base/content/tabbrowser.xml => browser/base/content/tabbrowser-tabs.js
extra : source : c163881a80c9a032b40f7d965fad6a6850fcf8a4
extra : intermediate-source : a5c6deeda8a9475ac0268a4351417c8ff659c962
extra : histedit_source : 5eb8b3d14027f2aeca5c52534096837cd0343104%2Ca23a07ddd5e1fb8bd084644dd6db0ee028b7c4b4
A bunch of existing code assumes that <tab> elements are the immediate
and only children of a <tabs> element, and uses dom apis to traverse
relationships between these elements. To simplify conversion of <tabs>
to a custom element (and hopefully improve readability a bit at the same
time!), introduce new apis:
On <tab>
this.parentNode -> this.container
this.nextElementSibling -> this.container.findNextTab(...)
this.previousElementSibiling -> this.container.findNextTab(...)
On <tabs>
this.children -> this.allTabs
Differential Revision: https://phabricator.services.mozilla.com/D34648
--HG--
extra : source : f4e21e465f384b90fa1e768141c4db708748bf66
extra : histedit_source : 95d8a4242e8e04df9e29c2b647558d37e910b845
This patch update the telemetry event definition for the addonsManager.install and
addonsManager.manage telemetry events, to mention the "rtamo" telemetry source
that is going to be used by ActivityStream on the addon installed from the
"Return To AMO" onboarding, and also list all the other values currently used
for the "source" and "method" extra keys (they were initially listed in the
initial data review request, but they have never been listed in the event definition
yet).
Differential Revision: https://phabricator.services.mozilla.com/D34405
--HG--
extra : moz-landing-system : lando
This does two things:
- Makes times relative to current time, with the only constraint that not a
whole second may pass after the first frame, since that will trigger the
same-frame timer.
- Changes asserts to use TimeDuration instead of TimeStamp for understandable
logs.
This has proven needed on some macosx machines.
Differential Revision: https://phabricator.services.mozilla.com/D36217
--HG--
extra : moz-landing-system : lando
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
--HG--
extra : moz-landing-system : lando
We use Cmd/Ctrl + B to switch between inline and editor mode. This
should be familiar for VSCode users as it toggles the file sidebar.
When changing the layout, we persist the choice into the editor pref
so the user keeps the same layout the next time they open the console.
Differential Revision: https://phabricator.services.mozilla.com/D34718
--HG--
extra : moz-landing-system : lando
When the editor preference is true, a CSS class is added to
the panel that allow us to shift the layout to a CSS Grid, where
the input panel is on the left and the output on the right.
A toolbar is added to be able to execute an expression when in
editor mode.
Differential Revision: https://phabricator.services.mozilla.com/D17096
--HG--
extra : moz-landing-system : lando
This patch is based on Makoto Kato-san's patch.
This patch implements `mozilla::dom::StaticRange` class and creating some
static factory methods.
Then, makes `AbstractRange` has a utility method of `SetStartAndEnd()`
method of `nsRange` and `StaticRange` for sharing same logic in one place.
However, there are some additional work is required only in `nsRange`, e.g.,
`nsRange` needs to start observing mutation of the range, but `StaticRange`
does not it. Therefore, it's implemented as a template method which takes
`nsRange*` or `StaticRange*` as a parameter. Then, each `DoSetRange()`
method of them can do different things without virtual calls.
Note that `StaticRange` does not have any properties, methods nor constructor.
Therefore, we need additional API to test it.
Differential Revision: https://phabricator.services.mozilla.com/D35143
--HG--
extra : moz-landing-system : lando
Some `nsRange` static methods are useful in `StaticRange` and some of them
are used in a lot of places but not related to `nsRange` directly. This
patch moves them into new static method only class, `mozilla::RangeUtils`.
Differential Revision: https://phabricator.services.mozilla.com/D35142
--HG--
extra : moz-landing-system : lando
For avoiding confusion between API of `nsRange` and `StaticRange`, I'd like to
rename `nsRange::CreateRange()` to `nsRange::Create()` because
`StaticRange::CreateStaticRange()` is too long name and
`StaticRange::CreateRange()` sounds odd. This patch renames it and changes
related methods to template methods to avoid runtime cost of temporary
`RawRangeBoundary` instance creation.
Differential Revision: https://phabricator.services.mozilla.com/D35141
--HG--
extra : moz-landing-system : lando
This patch is based on the patch created by Makoto Kato-san.
`Range` and `StaticRange` have common base interface, `AbstractRange`.
https://dom.spec.whatwg.org/#abstractrange
This interface has simply returns `startContainer`, `endContainer`,
`startOffset`, `endOffset` and `collapsed`.
Different from the original patch's approach, this patch moves related
members in `nsRange` to `AbstractRange` since this approach avoids
virtual call cost. Additionally, this patch makes them not throw as
declared by the spec. As far as I know, the destruction cost of
`ErrorResult` may appear in profile so that we should avoid creating
the instance if we can avoid it.
Unfortunately, the instance size of `nsRange` becomes larger with this
patch. The size is changed from 176 to 184. I.e., now, `nsRange`
requires bigger chunk.
Differential Revision: https://phabricator.services.mozilla.com/D35140
--HG--
extra : moz-landing-system : lando
We take this as an opportunity to fix the alignment between the XHR
badge and the URL.
Differential Revision: https://phabricator.services.mozilla.com/D36297
--HG--
extra : moz-landing-system : lando
In the future we're going to want VideoBridge connections from the RDD process into both the parent process and the GPU process.
This does the preparation work for unifying the way we create VideoBridges (using Endpoints, required for cross-process connections),
and detects which one to use based on where the video will be composited.
Differential Revision: https://phabricator.services.mozilla.com/D35968
--HG--
extra : moz-landing-system : lando
Sylvestre Ledru
Kartikaya Gupta
David Major
Markus Stange
Valentin Gosu
Julien Wajsberg
Nihanth Subramanya
krubin
Andrei Oprea
Paul Bone
Jan de Mooij
Stephen Donner
Karan Sapolia
Honza Bambas
Mohd Umar Alam
Julian Descottes
Masatoshi Kimura
Andrew Swan
Luca Greco
Alexandre Poirot
Andrey Lushnikov
Razvan Caliman
Drew Willcoxon
Andreas Pehrson
Emilio Cobos Álvarez
Nicolas Chevobbe
Makoto Kato
Masayuki Nakano
Timothy Nikkel
Matt Woodrow