During the pagehide event, we're checking that the target we're navigating away
from is the expected one.
We previously used the window property, but this is a getter that is updated when
a document is selected in the iframe picker.
Since the goal is to check the actual document the target was created for, we
can use the originalWindow property instead.
A test is added, which is failing without the fixes of this patch.
We take this as an opportunity to clear the iframe picker list on will-navigate,
(as the test was failing on Fission without this), which allows us to remove the
`_notifyDocShellDestroyAll` method of the `BrowsingContextTargetActor` that was
also called before emitting the `will-navigate` event.
Differential Revision: https://phabricator.services.mozilla.com/D121727
With the patch above, some devtools tests failed because we were trying
to call getComputedStyle(node, ":marker") (read: one colon rather than
two).
Using two colons for pseudo-elements is the right thing to do and fixes
it / removes some weird special-cases.
Differential Revision: https://phabricator.services.mozilla.com/D121858
For context, see the bug conversation. We have a class of issues on popup related tests on linux webrender.
I suspect they are triggered because we don't have a presShell yet when we try to create popups.
This patch adds a waitForPresShell helper in shared-head, and uses it from the createHost test helper, which is used by most of the failing tests, as well as from a specific test: browser_enable_devtools_popup_new_user.js
Differential Revision: https://phabricator.services.mozilla.com/D121798
We used to set doNotFireFrameUpdates on all the target actors
created from the server, and as a result, we would never populate
the iframe dropdown.
The original concern was that since we can have multiple targets
now (when fission is enabled), different frameUpdate events would
be fired which would cause issues in the iframe dropdown.
But at the moment, we know that the iframe dropdown does not support
Fission (remote frames are not displayed), as the toolbox only listen
for frame-update events emitted from the top-level target.
With this patch, we'll emit frameUpdate event only from top-level targets,
so we don't send unnecessary RDP packet to client.
A test is added that checks multiple scenarios with pages adding and
removing iframes, as well as navigating so we can assert the dropdown
berhaviour with server side targets.
The test is tagged as fail-if on Fission as we're missing remote frames
in the dropdown.
Differential Revision: https://phabricator.services.mozilla.com/D121601
break-before/after: page|column seem harder because you need to deal
with nested breaks, I think, but this should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D121206
break-before/after: page|column seem harder because you need to deal
with nested breaks, I think, but this should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D121206
The call to restoreActor state was inferring with the watcher setting up the configuration
on new documents, and was making browser_max_touchpoints and browser_touch_pointerevents
fail with server side target switching.
Differential Revision: https://phabricator.services.mozilla.com/D121533
The test times out with server side target switching as the
storage actor gets created earlier than the cache and the
storage inspector doesn't update when CacheStorage is
updated (see Bug 1712757).
Differential Revision: https://phabricator.services.mozilla.com/D121504
it could happen that the page wasn't loaded yet, which would
make the call to gBrowser.goBack() a no-op and messing up
the rest of the test.
Differential Revision: https://phabricator.services.mozilla.com/D121347
For some reason, having a function with this name makes TypeScript show an
error for frame-script.js, which also has a function with the same name and
a different signature. Renaming the worker function fixes the TypeScript
error - even though TypeScript doesn't even check the worker script!
Differential Revision: https://phabricator.services.mozilla.com/D121252
This prepares the worker for an upcoming update to a new profiler-get-symbols version;
this way of doing things is a much better match for the new API.
For requesting a single symbol table, this may look unnecessarily complicated, and it is.
But it paves the way for requesting symbols for multiple libraries in a single message.
In the future, rather than requesting a full symbol table for a single library, we will
want to have a queryAPI endpoint which lets us request symbols for multiple libraries
with a single message. This is just elaborate preparation for that step.
Differential Revision: https://phabricator.services.mozilla.com/D120188
After I wrote this patch, I noticed that the worker isn't actually covered
by TypeScript because it doesn't have a `// @ts-check` comment.
But it seems to be rather non-trivial to make it pass type checking, especially
around module import. For example, I don't know how to tell TypeScript that
this code runs in a worker global scope which has an importScripts function.
So I'm just going to leave the worker uncovered for now. I hope the JSDoc
comment doesn't give the wrong impression.
Differential Revision: https://phabricator.services.mozilla.com/D120184
An upcoming patch will remove the other use of `createLibraryMap` (because the
map lookup moves into the worker), so with both uses removed, we'll be able to
remove the function.
This shouldn't noticeably affect performance, because this case is rarely hit
and because the array never has more than 1000 items, so even a linear search
is really fast.
Differential Revision: https://phabricator.services.mozilla.com/D120179
Marian-Vasile Laza
Nicolas Chevobbe
Butkovits Atila
Nika Layzell
Jon Bauman
Dorel Luca
Emilio Cobos Álvarez
Kagami Sascha Rosylight
Julian Descottes
Kiran Ghanekar
Markus Stange
Alexandru Michis
Noemi Erli
Daisuke Akatsuka
Christoph Kerschbaumer
Iulian Moraru
Sandor Molnar
Hubert Boma Manilla
Zibi Braniecki