These 3 tests handle the profiler events themselves instead of using the
TalosParentProfiler or TalosContentProfiler that already do this. But these
tests were only adding an "instant" marker at the end of the subtest.
This patch changes these "instant" markers into "duration" markers by providing
a `startTime` argument in their options object. If `startTime` is provided they
are already considered a duration marker by adding the `endTime` as
`performance.now()`.
This patch also changes the arguments that are passed inside the
`ChromeUtils.addProfilerMarker` calls. This makes the markers a lot better in
the profiler UI by grouping them inside a single row instead of showing them
individually, and allocating a lot more space in the viewport.
Differential Revision: https://phabricator.services.mozilla.com/D191358
The marker strings in the `subtestEnd` calls will show up in the profiles as
markers. But they will show up as a duration marker that starts when the
subtest starts and ends when the subtest ends. That's why naming them as "test
end" doesn't make sense. They are both the start and end.
Differential Revision: https://phabricator.services.mozilla.com/D191357
Previously we were pausing the profiler right after starting it. Then we were
resuming it right before each subtest. Then at the end of the subtest were
pausing it again. I believe this was done to make the testing areas visible.
But we now have profiler markers to show the testing duration/times instead of
pausing and resuming the profiler all the time. It doesn't add value to
pause/resume it, instead it actually loses some information like GC that
happens right after the test.
So instead of pausing and resuming the profiler all the time, this patch
removes this logic completely. We don't really need to pause the profiler
between the tests at all. This will also fix the issues like Bug 1838824, where
the profile data is completely empty because we fail to pause/resume the tests
where they handle the test measurements themselves.
Differential Revision: https://phabricator.services.mozilla.com/D191356
AFAICT the browser-addons.js code is unused.
The AM code is untested, at best, but probably unused after the demise of the disco pane.
Either way, using browsingContexts to determine the toplevel browser seems better and is
easier to read.
Differential Revision: https://phabricator.services.mozilla.com/D191425
Don't render the whole React app in a main tab, instead move the
main element to wrap the editor.
Don't use a list for rendering the secondary panels, but <aside> elements,
so they can be access through landmark navigation.
Make the different article labelled by the h2 we already have there.
Differential Revision: https://phabricator.services.mozilla.com/D190446
The TTL refresh is done asynchronously with low priority on windows.
When clearing the cache between tests, this callback may still exist
so it may refresh the cache entry with the native value instead of the TRR one.
Differential Revision: https://phabricator.services.mozilla.com/D191399
The frame elements already had the correct roles assigned,
but this was made completely useless because we had a
`display: contents` on them, which strips any accessibility role.
This was done for layout purpose that we now can do with
subgrids, so we update the component's CSS.
We also update the markup so copying stacktrace still works as expected.
A webconsole test is added to ensure those stactkrace frames
can be navigated with the keyboard.
Differential Revision: https://phabricator.services.mozilla.com/D190594
In `getTokenLocation`, the call to `coordsChar` needed an extra parameter so the
coordinates are relative to the top left corner fo the currently visible window.
We were passing the center of the bounding client rect to `getTokenLocation`, but
a token could wrap and have it's bounding rect center not being on the token.
To fix this we're passing the center of the first box quads of the token.
The inline preview widgets were causing some troubles on CodeMirror internal
state too. Since we're using React to populate the bookmark we set on the line,
and given that React.render is asynchronous, we were setting an empty element
as a bookmark on the editor, which React populates later. But CodeMirror probably
update its internal state when the bookmark is added, so that was causing wrong
computation later.
To avoid that, we only set the bookmark once React actually rendered the element
in the DOM.
Finally, while codeMirror already listen for window resize to update its internal
state, the Editor can be resized without the window being resized,
when primary/secondary panels are resized. In such case, we manually trigger
a codeMirror refresh.
We add a test to cover this, and also modify test helpers so we would query
the DOM instead of relying on CodeMirror methods.
Differential Revision: https://phabricator.services.mozilla.com/D190272
As discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=1837533#c9 , this
test had two sections that were making extra assumptions about what the default
line-height:normal value resolves to. This commit avoids those assumptions by
breaking the chain of influence between the resolved 'line-height' value and
the actual rendering in these two sections -- in one case by setting an
explicit 'height', and in the other case by setting an explicit 'line-height'.
Differential Revision: https://phabricator.services.mozilla.com/D191490
Updates the ICU patch "double-conversion.diff" to only use the in-tree copy of
double-conversion when building Firefox/SpiderMonkey. Standalone ICU builds
instead use the ICU copy of double-conversion. Standalone ICU builds happen
when running "intl/icu_sources_data.py" and when converting the in-tree
little-endian ICU data file to the big-endian format.
`JS_HAS_INTL_API` is used to detect how ICU is built: When building ICU as part
of Firefox/SpiderMonkey, `JS_HAS_INTL_API` is guaranteed to be set, whereas in
standalone ICU builds `JS_HAS_INTL_API` isn't defined.
After applying the updated "double-conversion.diff" patch, ICU was reimported
to restore the previously deleted double-conversion sources files from ICU.
Depends on D190791
Differential Revision: https://phabricator.services.mozilla.com/D190792
test_redirect_http_equiv is currently failing for Firefox, which might either be from a platform bug or something we have to workaround in
Bug 1859545
Differential Revision: https://phabricator.services.mozilla.com/D191202
This is just extending our existing progress-listener object that we use
functionally in the test, to implement a few more of the nsIWebProgressListener
callbacks so we can see if they're firing in some unforeseen way that can help
us identify why the test is intermittently timing out.
I'm just cribbing the full list of callbacks from
https://searchfox.org/mozilla-central/source/uriloader/base/nsIWebProgressListener.idl
without worrying too much about their applicability here.
Differential Revision: https://phabricator.services.mozilla.com/D191501
