This was relevant before as we were calling "ThreadActor.getSources"/"StyleSheets.getStyleSheets",
and by the time these requests resolved, we would have navigated to a new URL and need to ignore their response.
I think it is safe to drop this now as these requests may still be pending if we use legacy listeners,
but the call to unwatchResources should immediately unregister _onResourceAvailable and ignore any pending data
coming late.
Differential Revision: https://phabricator.services.mozilla.com/D90428
In many cases with wpt, most of the tests in the file pass, but it is rather time consuming to annotate
.ini files case by case.
Differential Revision: https://phabricator.services.mozilla.com/D91977
/!\ in order to take the new package in packages/ folder in account,
you have to run `yarn` before `node bin/bundle.js`
Differential Revision: https://phabricator.services.mozilla.com/D91732
This is done by doing:
$ cd devtools/client/debugger
$ yarn
$ node bin/bundle.js
I'm doing this first in order to better highlight the impact of introduce new packages in-tree.
Differential Revision: https://phabricator.services.mozilla.com/D91731
This patch adds a simple WorkerTargetActor, which is similar to the mock target
actor we had in startup/worker.js.
Its spec file is empty at the moment, and it does not have an associated front,
but that might change with Bug 1633712 where we will at least have events for
resources available/destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D91128
This renames the current WorkerTargetActor which is actually a descriptor.
We also rename the existing `workerTargetFront` occurences to `workerDescriptorFront`
to avoid confusion when we do introduce the real worker fronts and actors.
Differential Revision: https://phabricator.services.mozilla.com/D91100
This patch adds a simple WorkerTargetActor, which is similar to the mock target
actor we had in startup/worker.js.
Its spec file is empty at the moment, and it does not have an associated front,
but that might change with Bug 1633712 where we will at least have events for
resources available/destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D91128
This renames the current WorkerTargetActor which is actually a descriptor.
We also rename the existing `workerTargetFront` occurences to `workerDescriptorFront`
to avoid confusion when we do introduce the real worker fronts and actors.
Differential Revision: https://phabricator.services.mozilla.com/D91100
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
In Bug 1660416, the separator element in the list of context was turned
into an hr element. But the test helper that checks the list wasn't updated,
which made the test fail (the test only runs when fission is enabled, which
is why it wasn't backed-out).
This patch fixes the helper by retrieving hr elements from the list.
Differential Revision: https://phabricator.services.mozilla.com/D90820
Because of this, in netmonitor stubs tests, the resource objects ends up loosing
"intermediate" state and now contains all information that we gathered by the time
we emit throttled resources.
The only way to address that would be to do an archived copy of each resource state,
but I don't think we want to do that...
Differential Revision: https://phabricator.services.mozilla.com/D89628
Before this patch the CodeMirror instance used to create Conditional Breakpoints and Logpoints did not have placeholder text.
This patch adds placeholder text to this CodeMirror instance by:
1. Adding the CodeMirror addon responsible for creating placeholder text.
2. Updating `webpack.config.js`.
3. Regenerating `codemirror.bundle.js`.
4. Matching the color of the placholder text in these CodeMirror instances to the color of placeholder text in the rest of the Debugger.
{F2456834}
Differential Revision: https://phabricator.services.mozilla.com/D89962
This patch renames the internal -moz-math-display to math-style and
exposes it under the layout.css.math-style.enabled preference. The
initial value becomes "normal" but that does not affect the default
MathML behavior since the UA style sheet sets the math-style property
explicitly on <math> tags. WPT tests are updated to use the syntax
approved by the CSSWG.
Intent to prototype: https://groups.google.com/forum/#!msg/mozilla.dev.platform/1hQQ7ISudGo/_yLEckEeBQAJ
Differential Revision: https://phabricator.services.mozilla.com/D90731
This help modifying redux state only once and prevent many uncesarry copies of the whole messages/network events Maps.
This will also later help getting rid of WebConsoleWrapper throttling in favor of upcoming ResourceWatcher one,
as we could call only one action from onResourceAvailable/Updated.
Differential Revision: https://phabricator.services.mozilla.com/D90367
This patch renames the internal -moz-math-display to math-style and
exposes it under the layout.css.math-style.enabled preference. The
initial value becomes "normal" but that does not affect the default
MathML behavior since the UA style sheet sets the math-style property
explicitly on <math> tags. WPT tests are updated to use the syntax
approved by the CSSWG.
Intent to prototype: https://groups.google.com/forum/#!msg/mozilla.dev.platform/1hQQ7ISudGo/_yLEckEeBQAJ
Differential Revision: https://phabricator.services.mozilla.com/D90731
This will ultimately help get rid of throttling done in WebConsoleWrapper
in favor of the upcoming one to be done from ResourceWatcher.
Differential Revision: https://phabricator.services.mozilla.com/D90366
If we open the Compatibility panel, the rules panel ill import the
tooltip.css for rendering the tooltips. However, the tooptip.css
imports compatibility.css and now the styles are not only unnecessarily
parsed but also on opening the Compatiblity panel, this stylesheet is
loaded and parsed again leading to the stylesheet
being loaded twice and hence these styles are applied twice for
each element in the compatibility panel unnecessarily.
We get all the necessary styles for the compatibility tooltip into
the tooltip.css (adding the necessary changes needed to handle the
color differences in the background) and remove the import of the
external compatibility.css
Differential Revision: https://phabricator.services.mozilla.com/D90533
Before this patch, there were some UX polish issues present in both the Watch Expressions and the XHR Breakpoints pane. These issues were:
1. Whenever a list of elements was displayed in either of these panes it did not possess the `4px` of vertical `padding` that is typical of lists in the Debugger.
2. The Add Watch Expression input was often not removed from the UI until after the updated list of Watch Expressions was rendered.
3. Whenever a user attempts to edit an existing Watch Expression or XHR Breakpoint they experienced significant "vertical bounce" due to a difference in height between the original markup and the form that replaced it.
This patch addresses these issues by:
1. Relocating the inputs used to create new Watch Expressions and XHR Breakpoints outside of the `<ul>` elements in these panes.
2. Relocating the `hideInput()` function call to `componentWillReceiveProps()` ensuring that the Add Watch Expression input does not persist after the list of Watch Expressions has been updated.
3. Modifying the height of the forms used to edit existing Watch Expressions and XHR Breakpoints so that there is no vertical bounce whenever a user attempts to edit an existing Watch Expression or XHR Breakpoint.
In addition to these changes, Snapshot tests and Mochitest selectors were updated where relevant while minor refactors were also done in order to improve the legibility of the code.
{F2447136}
Differential Revision: https://phabricator.services.mozilla.com/D88101
This patch renames the internal -moz-math-display to math-style and
exposes it under the layout.css.math-style.enabled preference. The
initial value becomes "normal" but that does not affect the default
MathML behavior since the UA style sheet sets the math-style property
explicitly on <math> tags. WPT tests are updated to use the syntax
approved by the CSSWG.
Intent to prototype: https://groups.google.com/forum/#!msg/mozilla.dev.platform/1hQQ7ISudGo/_yLEckEeBQAJ
Differential Revision: https://phabricator.services.mozilla.com/D90731
This revision introduces throttling for the color picker widget used in the DevTools Inspector Rules view.
The color picker widget can emit a lot a requests when clicking and dragging the mouse on the color "palette".
Locally I measured up to 200 requests per second. Since each request needs to apply the color to the element before the next request can be processed, this results in a bad user experience where requests will keep being applied for several seconds after the user finished using the widget.
Using throttling allows to cap the number of requests we emit, while still making sure the last value is correctly sent to the server.
Differential Revision: https://phabricator.services.mozilla.com/D90530
Depends on D90248
This patch combines two test helpers into one: removes `getRuleViewSelectorHighlighterIcon()` and folds its logic into `clickSelectorIcon()`.
The other callsites for `getRuleViewSelectorHighlighterIcon()` are removed in D90250.
The augmented `clickSelectorIcon()` will toggle the selector highlighter accordingly (on or off for the given selector depending on its current state). It returns a promise that resolves with the event data from either the "highlighter-hidden" or "highlighter-shown" events emitted by the selector highlighter. Tests check this data for the expected results.
Tests no longer use mocks for selector highlighter. They test the real thing.
Differential Revision: https://phabricator.services.mozilla.com/D90249
Depends on D90247
The new React-based Rules view is a stalled project, but not yet abandoned.
This patch updates the logic to toggle the selector highlighter so it doesn't fall too far behind in parity with the legacy but still active Rules view.
Flip this pref to test the new Rules view: `devtools.inspector.new-rulesview.enabled`.
It will add a new Rules panel to the Inspector sidebar at the far right end of the tabs.
To avoid confusion and bugs, disable 3-pane mode so you only see one Inspector sidebar panel at a time.
Differential Revision: https://phabricator.services.mozilla.com/D90248
Depends on D90246
This patch updates the logic to toggle the selector highlighter (icon next to CSS selectors in the Rules view) using the process-agnostic approach introduced in `HighlightersOverlay`.
There are 3 main chunks of logic:
- A) Introduce event delegation in the Rules view (`CssRuleView.handleEvent()`)
- B) Introduce generic handler for highligther events in Rules view (`CssRuleView.handleHighlighterEvent()`)
- C) Toggle the selector highlighter using the `HighlightersOverlay.showHighlighterTypeForNode()`/`HighlightersOverlay.hideHighlighterType()` methods with the `SELECTOR` highlighter type.
### Part A
With Part A, CssRuleView.handleEvent(), we're laying the groundwork to have the Rules view react to events within its DOM tree.
Currently, `HighlightersOverlay` is doing too much. Along with managing highlighters, it acts as an event delegate for the Rules view and Computed view via [HighlightersOverlay.addToView()](https://searchfox.org/mozilla-central/rev/0c97a6410ff018c22e65a0cbe4e5f2ca4581b22e/devtools/client/inspector/shared/highlighters-overlay.js#415-428). This adds [cumbersome logic to check the target](https://searchfox.org/mozilla-central/rev/0c97a6410ff018c22e65a0cbe4e5f2ca4581b22e/devtools/client/inspector/shared/highlighters-overlay.js#1402-1428) of an event in order to know whether to react to it. This isn't wrong per-se, but it concentrates DOM knowledge from a broad part of the Inspector away from where it is generated.
Ideally, `HighlightersOverlay` should only manage highlighters. It should be called from various endpoints without regard to who is calling and in reaction to which events.
The intent is to reuse this `CssRuleView.handleEvent()` for:
- toggling the CSS Transforms Highlighter by reacting to mouseover events from corresponding CSS values
- toggling the Flexbox / Grid / Shapes highlighters by reacting to clicks on corresponding swatch icons next to CSS values
### Part B
Part B, `CssRuleView.handleHighlighterEvent()`, adds a generic highlighter event handler to the Rules view. Checking the event name and highlighter type, the Rules view can update itself in reaction to highlighters triggered from elsewhere in the Inspector.
In this patch, we're using it to toggle the active CSS class name on the selector highlighter icon in response to "highlighter-shown" / "highlighter-hidden" events of the `SELECTOR` highlighter type.
Probably a bit overkill here. But it gets more useful with the Flexbox and Grid Highlighters which have call sites in multiple places with indicators that need to be reconciled:
- Flex/Grid badges in Markup view
- Checkboxes in Layout panel
- Swatch icons for Flex and Grid in Rules view
### Part C
Part C replaces the legacy toggling logic for selector highlighter with the abstract methods in `HighligthersOverlay`, does some slight clean-up, and fixes some bugs in the previous implementation.
All CSS rules matching the same selector will be marked when the selector is active (see inline comment)
When editing a selector, the selector highlighter for another CSS rule will no longer be hidden (see inline comment)
Differential Revision: https://phabricator.services.mozilla.com/D90247
This help modifying redux state only once and prevent many uncesarry copies of the whole messages/network events Maps.
This will also later help getting rid of WebConsoleWrapper throttling in favor of upcoming ResourceWatcher one,
as we could call only one action from onResourceAvailable/Updated.
Differential Revision: https://phabricator.services.mozilla.com/D90367
This will ultimately help get rid of throttling done in WebConsoleWrapper
in favor of the upcoming one to be done from ResourceWatcher.
Differential Revision: https://phabricator.services.mozilla.com/D90366
Some tests made some assumptions about the number of returned entries
by performance.getEntries, and these assumptions are not valid
anymore once we added new entries.
Depends on D66463
Differential Revision: https://phabricator.services.mozilla.com/D68645
Instead of replicationg the browser list fetch using the
preference on the server side, we send the browser list from the
client side to the CompatibilityActor to get the declaration block
compatibility issues.
This way the pref setting is retained completely on the client
side and server doesn't have code duplication.
Differential Revision: https://phabricator.services.mozilla.com/D87613
This moves the MDNCompatibility library and the related datasets
and tests to the server side. It also moves the compatibility actor
file intot he compatibility directory.
The links to these files have been updated and the library tests have
been moved to the new location.
Differential Revision: https://phabricator.services.mozilla.com/D86521
Most of the client side imports from the MDNCompatibility library
is to access the MDNCompatibility.ISSUE_TYPE property.
This patch moves the property into devtools/shared/constants.js
from where it can be accessed on both the client and server side.
Differential Revision: https://phabricator.services.mozilla.com/D86519
The callee getter returned |undefined| for certain functions because it's
hard to recover the callee consistently for all environments (and we can't
return the internal canonical function). See also bug 1414684.
This patch fixes that by exposing the script instead of the callee. Devtools is
only interested in the displayName and parameterNames properties and those are
also available on scripts (the previous patch adds Script.parameterNames).
Differential Revision: https://phabricator.services.mozilla.com/D89701
Depends on D85863
Follow-up for code review https://phabricator.services.mozilla.com/D81526#inline-471516
Renaming existing events emitted on behalf of `CssTransformHighlighter` to avoid conflict and confusion with the generic show/hide highlighter events introduced in HighlightersOverlay. When migrating the CssTransformHighlighter to the Fission-ready highlighters approach, these event names will go away completely.
Differential Revision: https://phabricator.services.mozilla.com/D89570
Depends on D85859
The Box Model diagram in the Layout sidebar panel of the Inspector shows a Box Model Highlighter on hover over its components parts: margin, border, padding, content.
This patch routes the calls to the highlighter to use the approach introduced in `HighlightersOverlay` in D81526
Differential Revision: https://phabricator.services.mozilla.com/D85860
Depends on D85858
The Markup view uses the highlighter in a few places:
- while hovering over nodes in the node tree
- while hovering over nodes in the breadcrumbs view under the node tree
- after clicking a node from the node tree, a highlighter is shown, then it is automatically hidden after a delay
This patch routes all calls to show and hide the highlighter to the newly implemented approach in `HighlightersOverlay` which ensures hiding existing instances before showing others regardless of target.
A slight change is made in `HighlightersOverlay` to allow passing in an option to automatically hide the highlighter after a delay. This removes the need for discrete handling of timers within the markup view (removes [_brieflyShowBoxModel](https://searchfox.org/mozilla-central/source/devtools/client/inspector/markup/markup.js#742-756)) and enables reusing this mechanism with the Node Picker after picking (see `onPickerPicked` in [this diff](https://phabricator.services.mozilla.com/D81528?vs=321451&id=332813#toc) from D81528)
`HighlightersOverlay.showHighlighterTypeForNode()` no longer skips duplicate calls with the same highlighter type and nodeFront if the options provided are different between calls. This supports scheduling autohide on an already visible highlighter. Use case: in the node tree, hover over a node (shows highlighter), then click on the node (shows highlighter again, but schedules autohide after a delay)
NOTE: This automatic hiding after a delay can cause intermittent test failures. Slow running tests can find themselves without a highlighter midway through the checks. To mitigate this, while testing, highlighters are not automatically hidden. See `HIGHLIGHTER_AUTOHIDE_TIMER` in [this diff](https://phabricator.services.mozilla.com/D81528?vs=321451&id=332813#toc) from D81528. Tests which explicitly check the autohide behavior can reinstate `inspector.HIGHLIGHTER_AUTOHIDE_TIMER`.
Tests are updated to invoke actual highlighters and listen to their events. No more mocking.
Differential Revision: https://phabricator.services.mozilla.com/D85859
Depends on D81526
This patch updates tests pertaining only to node picker behavior. Run one-by-one, they're all expected to pass.
However, running the whole Inspector test suite at this point in the commit series will fail some other tests because:
- we're updating shared test helpers here without also updating the other tests;
- there is inter-dependence in the other tests between node picker and markup view which is being migrated to the new highlighters approach in D81530
The rest of the tests are getting updated in the subsequent patches in this commit series.
Differential Revision: https://phabricator.services.mozilla.com/D81528
Depends on D81525
Introduced a centralized way in `HighlightersOverlay` to invoke highlighters by type, automatically managing previously active highlighters.
First some context.
`HighlightersOverlay` is a bit of a misnomer. It already does a few things:
- provides methods to manually invoke some highlighters (Flex/Grid/Shapes/BoxModel)
- provides a way to delegate mouse events from Rules view / Computed view / Markup and invoke highlighters based on the event's target node
- manages state of Flex/Grid highlighters to be able to restore them on page refresh
- exposes the node that is highlighted by a particular highlighter
- misc handlers for events that require hiding highlighters by type (ex mutation events)
The changes in this patch add the core functionality which will automatically manage the visibility of highlighters regardless of their node's host frame:
- `this._activeHighlighters` is a Map which maps a highlighter type to the currently visible highlighter instance and its corresponding `NodeFront`
- `showHighlighterTypeForNode(type, nodeFront, options)` invokes a highlighter type for a given `NodeFront` while toggling off any existing highlighter for that type. For situations where multiple highlighters of the same type can be visible at the same time (ex: Grid), this is where we could manage their visibility.
- `hideHighlighterType(type)` hides all highlighters of a given type; can be followed-up with a more specific `hideHighlighterTypeForNode()` when needed
- `getNodeForActiveHighlighter(type)` returns the `NodeFront` currently highlighted by a highlighter type. This is an abstracted replacement for `flexboxHighlighterShown`, `geometryEditorHighlighterShown`, etc.
##### Accommodation for tests
To mitigate the fact that many tests and some consumers expect [exact event names](https://searchfox.org/mozilla-central/search?path=&q=-highlighter-shown) to be fired, like "box-model-highlighter-shown", instead of generic shown/hidden events with the highlighter type property as event data, we introduce a temporary map, `HIGHLIGHTER_EVENTS`, from which we pick the event to fire according to the highlighter type. As we progress in refactoring, the intent is for this map to slowly go away.
##### Intent for refactoring
The intent is for all client-side consumers to invoke highlighters via these methods. For example:
```
this.inspector.highlighters.showHighlighterTypeForNode(
"BoxModelHighlighter",
nodeFront
)
```
See another example of this in the migration of `FlexboxHighligther` in D79694.
##### Future plans
In the medium-term, it's likely we'll move this part of `HighligthersOverlay` from inspector to toolbox and rename it `HighlightersManager`. This way, other consumers, like Debugger and Console can also use it [instead of the existing approach](https://searchfox.org/mozilla-central/rev/027893497316897b8f292bde48dbb6da2391a331/devtools/client/framework/toolbox.js#3503-3557). Haven't attempted this yet. Pending updates to the Flexbox, Grid, Shapes and CSS Transform highlighters so when we migrate paths from `inspector.highlighters` to ⭐️ `toolbox.highlighters` is done in one go for all tests and consumers.
Differential Revision: https://phabricator.services.mozilla.com/D81526
I'm slicing this in this bug. This new resource type was added while I added the code for calling unwatchResources...
Differential Revision: https://phabricator.services.mozilla.com/D89625
I also added another early return in order to avoid trying to send a method response
if the actor is destroyed, as it isn't really useful and would also throw.
Both ifs added by this changeset fixes the test failure independently of the other one.
But I think we would benefit from both.
The one in writeError would avoid throwing exception in the last change catch handler
and so avoid unhandled promise rejections.
The one in sendReturn probably helps having more meaningful error report!
Differential Revision: https://phabricator.services.mozilla.com/D89682
Depends on D86162
The resource watcher already guarantees that listeners are only called once, caches resources etc.
Consequently, the client side logic currently implemented in the WalkerFront is redundant and should be removed.
Differential Revision: https://phabricator.services.mozilla.com/D86163
It looks like we forgot to re-enable this code.
Hopefully this doesn't break any test. Without that, DAMP is throwing
because of late onResourceAvailable calls.
This might tells us that the throttling should check if it is still
relevant to emit the throttled event? I'm not having such check yet.
Differential Revision: https://phabricator.services.mozilla.com/D89476
This isn't really related to EventLoop, but this is another exception thrown when running DAMP.
This time related to a request made against an already destroyed NodeFront.
Differential Revision: https://phabricator.services.mozilla.com/D89451
Depends on D87846
While testing the latest Fenix Nightly I noticed that the package name was org.mozilla.fenix.nightly
Differential Revision: https://phabricator.services.mozilla.com/D87847
To my knowledge, versionName should always be defined via init, but adding a default value here to avoid potential issues.
Differential Revision: https://phabricator.services.mozilla.com/D87846
At the moment, it is easy to break remote debugging by reading preferences incorrectly.
Typically, creating a preference in the firefox preference index file will only create it for Firefox, not for mobile (Fenix).
When trying to read the preference from the server with the Services.prefs.get*Pref APIs, the call will throw unless a fallback value was specified.
A longer term solution is investigated at https://bugzilla.mozilla.org/show_bug.cgi?id=1660182, but for now this changeset allows about:debugging to set a few default values for preferences when connecting to a remote runtime.
Differential Revision: https://phabricator.services.mozilla.com/D88782
Move the function taking care of closing the Browser Console to shared-head so
we can close it before closing the tabs opened during the test.
While attaching the worker, check that the Worker Debugger isn't closed, and
if it is, reject the promise. On the target list, catch rejection while attaching
and simply bail out so we don't call the rest of the code in onTargetAvailable.
Those guards are not enough to prevent any failure while attaching, so we're
wrapping calls to `attachAndInitThread`/`_onThreadInitialized` in try/catch
blocks to avoid test failures.
Differential Revision: https://phabricator.services.mozilla.com/D88766
At the moment, we don't have any guards in the targetList to _not_ execute the
creation/destruction listeners once the toolbox gets destroyed.
We only have a stopListening function on the targetList that is called when we
close the toolbox, but we can't rely only on that since it's also called when
doing a target switch (and working around that is very racy).
One solution would be to follow the common pattern we have everywhere by having
a destroy method that we would check before trying to call the listeners callback.
This might help with intermittent test failures.
Differential Revision: https://phabricator.services.mozilla.com/D88765
PDF print preview are using about:blank documents, which are ignored
by DevTools in order to save resources.
We avoid creating targets for these, very often, transcient documents.
I tried to find ways to distinguish typical temporary about:blank documents
from this print preview one.
Differential Revision: https://phabricator.services.mozilla.com/D88956
Some tests made some assumptions about the number of returned entries
by performance.getEntries, and these assumptions are not valid
anymore once we added new entries.
Depends on D66463
Differential Revision: https://phabricator.services.mozilla.com/D68645
The issue was that the getHighlighter request for the about:printpreview
target never settled. It appears that the document always stays in an
unitialized readyState, which was causing trouble.
Instead of relying only on readyState, we now call isDocumentReady, which
also checks if the document is loading.
Differential Revision: https://phabricator.services.mozilla.com/D87756
Reduces explicit "elem.style.x = 'y' assignments by consolidating them
into associated Objects, and using `Object.assign` to make the style
modifications to the respective elements."
Depends on D86866
Differential Revision: https://phabricator.services.mozilla.com/D86867
I had to put it in toolbox.css as it wasn't working from EvaluationContextSelector.css.
I imagine that's because the context DOM element are actually in toolbox document rather than the console one.
Also, React must be re-creating all DOM elements anytime there is an update
as you can see the list scroll up, everytime there is an update.
We should probably have a look at that as well.
Differential Revision: https://phabricator.services.mozilla.com/D87620
Some tests made some assumptions about the number of returned entries
by performance.getEntries, and these assumptions are not valid
anymore once we added new entries.
Depends on D66463
Differential Revision: https://phabricator.services.mozilla.com/D68645
Alexandre Poirot
Olli Pettay
Nicolas Chevobbe
Dorel Luca
Tom Schuster
Frederic Wang
Narcis Beleuzu
Mihai Alexandru Michis
Julian Descottes
Kris Maglione
Razvan Maries
Kyle Knaggs
Itiel
Kriyszig
Bogdan Tara
Ben
Cristina Coroiu
Razvan Caliman
Brindusan Cristian
Anurag Aggarwal
Sean Feng
Hubert Boma Manilla
Daisuke Akatsuka
Christoph Kerschbaumer
Jan de Mooij
Emilio Cobos Álvarez
Jeff Walden
Brad Werth
Csoregi Natalia
Gijs Kruitbosch
Andreea Pavel
manas
Anny Gakhokidze
Yury Delendik
Cosmin Sabou
Cody Welsh