Since the component renders asynchronously, consumers might
want to hook up to the actual first rendering.
We provide an `onRender` prop that will be called once, when
the component is ready.
Differential Revision: https://phabricator.services.mozilla.com/D14999
--HG--
extra : moz-landing-system : lando
Depends on D14839
We moved all negative delay path related tests to
`browser_animation_summary-graph_negative-delay-path.js`.
Thus, "delay-negative" test in
`browser_animation_summary-graph_computed-timing-path.js` duplicates.
In this patch, remove the duplicated test.
However, if we remove this test, the drawing area of the graph will be reduced
by that negative delay. So, we remove the test area which reduced at the same
time.
Differential Revision: https://phabricator.services.mozilla.com/D15064
--HG--
extra : moz-landing-system : lando
The calculation for firstSectionCount was wrong. In here, the firstSectionCount
should be min value of either fraction of iterationStart or iterationCount.
Differential Revision: https://phabricator.services.mozilla.com/D14838
--HG--
extra : moz-landing-system : lando
Since the component renders asynchronously, consumers might
want to hook up to the actual first rendering.
We provide an `onRender` prop that will be called once, when
the component is ready.
Differential Revision: https://phabricator.services.mozilla.com/D14999
--HG--
extra : moz-landing-system : lando
Depends on D14318. This patch introduces a setInterval to check if
new runtimes have appeared on monitored devices, directly from ADB. This is
one of the scenarios where we don't get an update from ADB. ADB is able to
track devices appearing or disappearing but here we are looking for a new
process, containing a specific string. Out of the box I don't think we can
do anything for this.
Maybe we could ask the devtools server to "broadcast" its presence when it
starts, but at the moment I am not sure how we should implement that.
Differential Revision: https://phabricator.services.mozilla.com/D14324
--HG--
extra : moz-landing-system : lando
Depends on D14709
So far, because we supported only single device, we could correspond to
disconnection by following code. From now, because we will support multi
devices, fix the code that changes the status.
Differential Revision: https://phabricator.services.mozilla.com/D14831
--HG--
extra : moz-landing-system : lando
Depends on D14310. This patch enables displaying devices on which the debuggable
runtime is not started yet. To test it, simply use an android phone with USB debugging enabled
but don't start Firefox yet. You should see the Unknown Runtime item in the sidebar.
Not that once you start Firefox on the device, you need to click refresh runtimes here to get
the sidebar to refresh (more on that in the last patch of the series).
Two things I am not completely happy with:
- calling this a runtime, when really it's just a device that has no runtime.
but I don't want to start renaming all our state for that. Hope we can treat it as
placeholder runtime, and forget about it.
- localization for the runtime item name can be done in many ways. Not using getString
at all makes things really complicated, but I'm open to suggestions if you have any
Differential Revision: https://phabricator.services.mozilla.com/D14313
--HG--
extra : moz-landing-system : lando
Depends on D14309. Relying on head_mocks will make it easier to
update the mocks when we start calling isUnknown() on our USB runtimes.
Differential Revision: https://phabricator.services.mozilla.com/D14310
--HG--
extra : moz-landing-system : lando
Depends on D14307. Introduce a placeholder UnknownAdbRuntime extending AdbRuntime.
AdbRuntime implements isUnknown(). This method is used to filter out the unknown runtimes in
webide and about:debugging. (filter will be removed in about:debugging in a patch in the same
queue)
Differential Revision: https://phabricator.services.mozilla.com/D14309
--HG--
extra : moz-landing-system : lando
The model information is duplicated between adb runtime and adb device.
This allows to keep the information in a single place.
Differential Revision: https://phabricator.services.mozilla.com/D14307
--HG--
extra : moz-landing-system : lando
Depends on D14589. I did a first cleanup when migrating the first
service worker test, but I think we can go a bit further, and this is not
strictly related to the new test I am about to add.
Differential Revision: https://phabricator.services.mozilla.com/D14590
--HG--
extra : moz-landing-system : lando
Looks like we missed this feature when doing the initial service worker support
so implementing here. UI-wise, I reused the same wording/positioning etc as in the current
about:debugging.
Note that this is another spot that uses client.request, so we will need to clean this up
when we finally add a front to represent service worker registrations.
Differential Revision: https://phabricator.services.mozilla.com/D14589
--HG--
extra : moz-landing-system : lando
This will help getting rid of another usage of Target.form.
And also helps instantiating only one WebConsole client.
Once WebConsole becomes a front, we can replace all the target.activeTab
to target.getFront("console").
Differential Revision: https://phabricator.services.mozilla.com/D14278
--HG--
extra : moz-landing-system : lando
This method is only used by target-from-url, it allows to return
a target got one precise top level window and instead of the whole main process.
It looks like it was the very last non-front/still-form target codepath.
Differential Revision: https://phabricator.services.mozilla.com/D14841
--HG--
extra : moz-landing-system : lando
Support unprefixed min-content and max-content and treat the prefixed
version as aliases for
1. width, min-width, max-width if inline-axis is horizontal, and
2. height, min-height, max-height if inline-axis is vertical, and
3. inline-size, min-inline-size, max-inline-size, and
4. flex-basis.
Besides, update the test cases to use unprefixed max-content and
min-content.
Depends on D7535
Differential Revision: https://phabricator.services.mozilla.com/D7536
--HG--
extra : moz-landing-system : lando
loadSubScript throws a string, without any stack/location.
Consider all string exceptions as coming from loadSubScript and re-throw a real error
object, coming with the stack of the require call.
Also handle wrong require path with a more explicit error message.
Differential Revision: https://phabricator.services.mozilla.com/D14139
--HG--
extra : moz-landing-system : lando
Nicolas Chevobbe
Daisuke Akatsuka
arthur.iakab
Bel?n Albeza
Julian Descottes
Razvan Maries
Jeff Walden
Logan Smyth
Andreea Pavel
Micah Tigley
Florens Verschelde
Alexandre Poirot
Bogdan Tara
Zibi Braniecki
Boris Chiou
Brindusan Cristian
yulia