This allows us to move away from using IsNavigating field in parent-controlled
paths. Use a new distinct error code in cases when we cancel loads in
Canonical BC due to another load starting. This way, we know to not reset the
urlbar if we are doing another load.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1721217#c10 for longer
explanation of what is going on here.
Differential Revision: https://phabricator.services.mozilla.com/D126845
This version aligns the FileHandle API with the new IOUtils SyncReadFile API, which saves a few lines of code.
It also fixes a panic which could occur if symbolication tried to do a large out-of-bounds file read.
This bad read range was computed due to incorrect parsing of the macOS 12 dyld shared cache format.
Depends on D132076
Differential Revision: https://phabricator.services.mozilla.com/D132077
The function, which is only used from previewers.js to retrieve
the first then interesting properties of an object, has a special
case for (local|session)Storage so we loop through their entries
and not their properties.
We're using storage#key to achieve this, but the problem is that
the function is quite slow, and if the storage object has a lot
of entries, it can end up freezing Firefox.
In order to avoid such freeze, for storage object, we're not returning
an array but an iterable object, which most of the time will only be
called 10 times and prevent any perf issue.
Differential Revision: https://phabricator.services.mozilla.com/D131913
We take this opportunity to merge the browser toolbox and content toolbox preferences
into a single one.
Depends on D131600
Differential Revision: https://phabricator.services.mozilla.com/D131770
At the moment, the overlay can't be displayed if the DOM isn't loaded,
and we were waiting for that state before trying to show the overlay.
But we can't move forward in the document loading process until we resume,
which mean we could end up in weird state with the overlay, where the
page wasn't paused anymore, but we'd display it.
In this patch, we simply bail out if the document isn't ready.
Differential Revision: https://phabricator.services.mozilla.com/D131884
At the moment, the overlay can't be displayed if the DOM isn't loaded,
and we were waiting for that state before trying to show the overlay.
But we can't move forward in the document loading process until we resume,
which mean we could end up in weird state with the overlay, where the
page wasn't paused anymore, but we'd display it.
In this patch, we simply bail out if the document isn't ready.
Differential Revision: https://phabricator.services.mozilla.com/D131884
We take this opportunity to merge the browser toolbox and content toolbox preferences
into a single one.
Depends on D131600
Differential Revision: https://phabricator.services.mozilla.com/D131770
At the moment, the overlay can't be displayed if the DOM isn't loaded,
and we were waiting for that state before trying to show the overlay.
But we can't move forward in the document loading process until we resume,
which mean we could end up in weird state with the overlay, where the
page wasn't paused anymore, but we'd display it.
In this patch, we simply bail out if the document isn't ready.
Differential Revision: https://phabricator.services.mozilla.com/D131884
The challenges here are:
* xpcshell tests still don't support the watcher actor and server side targets. So we have to ensure still using client side target fetched via Descriptor.getTarget RDP request. (We still also need that for WebExtension)
* some tests weren't spawning the TargetCommand while querying TabDescriptor.getTarget. I tuned them to call TargetCommand.startListening so that we start instantiating server side targets, including the top level one retrieved via TabDescriptor.getTarget.
Otherwise, thanks to this patch a few check can now be moved from `if (isLocalTab)` to `if (isTabDescriptor)`.
Differential Revision: https://phabricator.services.mozilla.com/D130761
This wasn't used except for a test and wasn't working with server side targets.
Making this compatible with SST wasn't trivial, so I went for removing this.
Differential Revision: https://phabricator.services.mozilla.com/D130919
This help any front to interact with commands, which is frequently useful.
In the long run, all fronts should be slowly converted to become commands.
Differential Revision: https://phabricator.services.mozilla.com/D131397
This was causing some issues with PausedDebuggerOverlay with EFT:
As we weren't returning the window to preEnter, we weren't calling
suppressEventHandling on it, which in the end made the call we
have in the overlay to setSuppressedEventListener inoperant.
This wasn't caught by the browser_dbg-paused-overlay-iframe.js test
we have as the method we use to simulate clicking on the button
(highlighterTestFront.clickPausedDebuggerOverlayButton), ends ups calling
the handleEvent method of the highlighter actor directly, bypassing the
regular flow of events in a paused page.
Differential Revision: https://phabricator.services.mozilla.com/D131654
We were always using the top level walker front, but as some tests are using iframes,
we need to use the node fronts dedicated walker front instead.
test_inspector-dead-nodes.html is purely skipped when EFT is enabled as it triggers
failures more frequently and it doesn't make much sense anyway (this test will be
migrated to a command test when we move walkerFront#children to a command).
Differential Revision: https://phabricator.services.mozilla.com/D131599
Fix two possible race conditions:
* short lived processes spawn by the test ends up breaking listAllWorkers where the listWorker request
made against a content process target is throwing because its DevToolsServerConnection is closed.
* the worker created by the test may actually still be visible to WorkerDebuggerManager,
so use a better technique to catch the WorkerDebugger's id.
Differential Revision: https://phabricator.services.mozilla.com/D131442
This adds `Localization` to `builtin-modules.js` to make it accessible from
`definitions.js`. It's likely that the abstractions used in `definitions.js`
will need to be revisited when `startup.properties` is also migrated to Fluent.
Differential Revision: https://phabricator.services.mozilla.com/D131219
This required 2 changes:
- fixing WatcherActor notifyTargetAvailable so we get notified about the iframe
target when doing a bfcache navigation (a test case is added in browser_target_command_bfcache.js as well)
- Checking is the target isn't destroyed in inspector onTargetSelected
Differential Revision: https://phabricator.services.mozilla.com/D131471
Well, the RDP method "detach" still exists, but is now destroying the target actor.
There is no more intermediate state where the actor is "detached" but not destroyed,
which is confusing and no longer useful now that we can longer attach again.
Differential Revision: https://phabricator.services.mozilla.com/D130916
This might make the leftover "detach" method a bit more special.
But ideally we would get rid of it and convert it to a call to target actor's destroy method.
Differential Revision: https://phabricator.services.mozilla.com/D130915
By doing that, we no longer have to ensure calling attach here and there.
Some followups will be helpful to get rid of detach and all mentions of attach/detach/attached.
Some code, like descriptors and tests are still calling attach, which is now a no-op.
Gettind rid of detach might be slightly more complicated.
Differential Revision: https://phabricator.services.mozilla.com/D130843
Calling attach was important to bootstrap the thread actor and retrieve its actorID.
But now with server target this is done early on and we already retrieve the actorID
via form(). Except for workers, but I fixed that.
The next patch will ensure that, on the server side we fully initialize the target actors
as soon as they are created.
Differential Revision: https://phabricator.services.mozilla.com/D130842
A new method is added in the HighlighterTestActor to retrieve information about
the highglighter.
The test highlights (pun intended) the issue described in Bug 1740509.
Differential Revision: https://phabricator.services.mozilla.com/D130875
The challenges here are:
* xpcshell tests still don't support the watcher actor and server side targets. So we have to ensure still using client side target fetched via Descriptor.getTarget RDP request. (We still also need that for WebExtension)
* some tests weren't spawning the TargetCommand while querying TabDescriptor.getTarget. I tuned them to call TargetCommand.startListening so that we start instantiating server side targets, including the top level one retrieved via TabDescriptor.getTarget.
Otherwise, thanks to this patch a few check can now be moved from `if (isLocalTab)` to `if (isTabDescriptor)`.
Differential Revision: https://phabricator.services.mozilla.com/D130761
This wasn't used except for a test and wasn't working with server side targets.
Making this compatible with SST wasn't trivial, so I went for removing this.
Differential Revision: https://phabricator.services.mozilla.com/D130919
Annotating each test individually lets us avoid introducing new failing tests
while we go through the backlog of failing tests.
Depends on D129162
Differential Revision: https://phabricator.services.mozilla.com/D129163
Annotating each test individually lets us avoid introducing new failing tests
while we go through the backlog of failing tests.
Depends on D129162
Differential Revision: https://phabricator.services.mozilla.com/D129163
Otherwise, the warning is displayed:
```
WARNING: Could not lex literal_block as "json". Highlighting skipped.
```
Depends on D131092
Differential Revision: https://phabricator.services.mozilla.com/D131093
The getBackgroundColor already has fallback paths for several situations.
We now use the fallback in case getAdjustedQuads returned an empty array.
A browser mochitest is added to cover this issue as well.
Differential Revision: https://phabricator.services.mozilla.com/D130750
Both window_bug1369072.html and browser_scroll.js have a pattern something like;
1) Call synthesizeKey to scroll an element
2) Wait a scroll event
3) Test something
4) (Re)set the scroll position to (0, 0) by calling Element.scrollTop and
Element.scrollLeft or scrollTo.
With the new transmogrification the step 4) will not reset the scroll position
if there's an on-going scroll animation in APZ triggered by the synthesizeKey.
To avoid the situation where there's an on-going animation at the step 4), we
destroy the corresponding scrollable frame and reconstruct it so that it
clobbers the animation.
Differential Revision: https://phabricator.services.mozilla.com/D130852
The method was throwing if the toolbox was opened with a panel different than
the inspector one but for which we do initialize the inspector front (e.g. Accessibility Panel).
Differential Revision: https://phabricator.services.mozilla.com/D130854
Those tests are passing with Fission enabled, as well as with EFT enabled.
it would be better to not skip them, so we remove the annotation, and use specific
assertions to handle cases where the tests shouldn't pass.
Differential Revision: https://phabricator.services.mozilla.com/D130244
This will allow panels to react to a given target being selected in the iframe picker
when EFT is enabled.
We add support for onTargetSelected in the inspector and add a few test cases
for it (checking that highlighters are hidden when selecting a frame, checking
that selecting an iframe and then removing it does update the markup view).
Differential Revision: https://phabricator.services.mozilla.com/D130177
The iframe picker code is refactored a bit so it's easier to follow.
This patch makes it so we support both EFT and non EFT scenarios.
Differential Revision: https://phabricator.services.mozilla.com/D130241
Those tests are passing with Fission enabled, as well as with EFT enabled.
it would be better to not skip them, so we remove the annotation, and use specific
assertions to handle cases where the tests shouldn't pass.
Differential Revision: https://phabricator.services.mozilla.com/D130244
This will allow panels to react to a given target being selected in the iframe picker
when EFT is enabled.
We add support for onTargetSelected in the inspector and add a few test cases
for it (checking that highlighters are hidden when selecting a frame, checking
that selecting an iframe and then removing it does update the markup view).
Differential Revision: https://phabricator.services.mozilla.com/D130177
The iframe picker code is refactored a bit so it's easier to follow.
This patch makes it so we support both EFT and non EFT scenarios.
Differential Revision: https://phabricator.services.mozilla.com/D130241
Using --theme-contrast-color. Sadly --theme-contrast-background looks pretty bad in dark theme, so we can't use the background color.
But the text color itself is fine against --theme-selection-background-hover, so let's use this
Differential Revision: https://phabricator.services.mozilla.com/D130754
The patch for Bug 1737993 did a very readable but not performant replacement
of lodash `without` usage in `getInScopeLines`.
This patch changes things a bit so we get a similar level of performance as
what we had before, when using `without`.
For this we :
- make `getOutOfScopeLines` returns a `Set` so checking inclusion is faster
- create the final array of "in scope lines" using a for loop and assigning
line number when needed, and then filtering out empty slots.
Differential Revision: https://phabricator.services.mozilla.com/D130742
This changeset adds a new shared helper which allows to wait for all the loaded panels of a toolbox.
We might use this by default in our navigation helper, but that should be done in a follow up.
Differential Revision: https://phabricator.services.mozilla.com/D130616
The 0 timeout wasn't enough on some platform, so we reload the page before calling
the method; since we're targetting an iframe that takes a few seconds to load,
the call should time out every time.
Differential Revision: https://phabricator.services.mozilla.com/D130612
The test is tagged as `fail-if= a11y_checks`, but as patch for Bug 1738124 switched
to Element.click, we don't get the expected failure anymore (since the a11y_check
task does not perform assertion on element.click).
Let's revert to the original behavior so we can still see that the test need
some a11y work.
Differential Revision: https://phabricator.services.mozilla.com/D130610
We're inlining the function directly in the only place where it's used.
We also make some changes to buildQuery to _not_ escape the negative lookbehind
that may be produced by the call to ignoreWhiteSpace.
Differential Revision: https://phabricator.services.mozilla.com/D129601
The function is expected to return a string, but was returning an array
if the associated node was dead.
This patch makes it return an empty string instead.
Differential Revision: https://phabricator.services.mozilla.com/D130175
`getAllSelectors` was used to retrieve a given nodeFront selector from the top
window (e.g. it would go up through documents).
This doesn't work with nodeFronts in remote frames, as we wouldn't be able to
reach for cross-process parent documents.
This patchs adds a new inspector command that computes the selector, reaching the
different documents.
All usages of `NodeFront#getAllSelectors` are switched to the new command, which
allows us to delete the method and another function that was only used there.
With the new command doing a bit more work, this highlighted some issue in our
codebase. Some consumers were relying on `selectionCssSelectors`, without waiting
for it to be updated when a new node was selected.
As a result a few tests were failing because of this.
So where it's possible and not perf critical, we simply compute the selector again.
We also emit a new event, `selection-css-selectors-updated`, so tests can wait
until it's properly set before doing further actions.
Differential Revision: https://phabricator.services.mozilla.com/D127928
Since the method might wait for iframe to load, it could stay unsettled for a
while.
Adding a timeout will make the callsites not wait for ever, at the expense of
correctness.
This should be okay as this function is mainly called to re-set things after
reloading the page, which is a nice to have, but not critical feature.
Differential Revision: https://phabricator.services.mozilla.com/D128854
At the moment we call `waitForFrameLoad`, the iframe `contentDocument` might be
a transient about:blank document, and in such case we weren't waiting properly for
it to be loaded.
To fix this, we wait until the final document is inserted first.
Tests will be added in another commit of this queue.
Differential Revision: https://phabricator.services.mozilla.com/D128713
The callsites are migrated to the new command, except from the webconsole test
in which we replace usage with existing inspector test helper.
Differential Revision: https://phabricator.services.mozilla.com/D128712
When loading an iframe in the same origin/process, we end up with an edge case.
A first "initial" about:blank document is created to bootstrap the iframe.
A `DOMWindowCreated` event is fired and its `document.isInitialDocument` is true.
If no URL is set on the iframe, it stops there and we won't create any target for this special document.
(As we ignore `DOMWindowCreated` events when `document.isInitialDocument` is true)
Then, if an URL is set on the iframe, we don't create any new WindowGlobal,
instead we will reuse the about:blank's document's one.
It means that there won't be any new DOMWindowCreated event.
Fortunately, there is a `DOMDocElementInserted` fired, which we can listen here.
We can then instantiate a target actor and that, only if no target was previously created
by a previous `DOMWindowCreated`. In all other cases, we would receive a `DOMWindowCreated`
with `document.isInitialDocument` set to false.
Differential Revision: https://phabricator.services.mozilla.com/D128456
Without this, the webconsole fails to execute anything after reloading the add-on document.
Can reproduce by running `location.reload()` in the console.
Differential Revision: https://phabricator.services.mozilla.com/D129009
There is a few things complex around WebExtension debugging:
* DevTools creates a browser element and connect to it.
The WebExtensionDescriptor instantiate its very own browser element
and DevTools codebase communicate to the extension process via this browser element.
We are still using the frame connector and message manager.
We do that especially to workaround add-on not having any document running (no background page, nor any popup).
Without that we wouldn't have any document and couldn't spawn any WindowGlobalTarget actor.
* We have a unique target, debugging many documents.
`webExtensionTargetPrototype._searchForExtensionWindow` will iterate over all document and try to
switch the WebExtensionTargetActor to another document.
This is based on `WindowGlobalTarget._setWindow` and so use the same magic hack
than the iframe dropdown to change the debugging document of a given WindowGlobal.
What is especially tricky about this is that we connect to the devtools specific browser element
in the parent process having one specific browserId, while in the content, we most likely
move the WebExtensionTargetActor to the background page, having a distinct browserId.
For a given extension, all their browser elements (background page, popups) are independant
and have distinct browserId.
Because of this we can't rely on the existing browser-element watcher context type.
We rather need to do a filtering the `addonId` which is correctly set on each document's principals.
Ideally, we would spawn one target for each of these browser elements.
To do that, we have to begin with supporting the watcher actor for webextension (purpose of this patch).
Then we would need EFT, otherwise the iframe dropdown would no longer work for webextension,
whereas that's a really key feature when debugging them.
All this is brittle, but there is a lot of chicken-egg issues here.
It would be best if we were spawning one Target for each individual extension document.
But to do that, we first need to start supporting the Watcher codepath.
Also, we would need EFT, otherwise the iframe dropdown would no longer work for extension documents.
Which is an important feature for add-ons debugging.
Note that for now, we don't watch for any additional targets when debugging a webextension.
(TargetCommand doesn't call watchTargets(FRAME))
In the meantime, we can at least start supporting the Watcher actor and server watchers,
but we will have to workaround the fact that we have a unique target, instantiated from the client,
by the descriptor. And this target may switch its focus to various documents.
Supporting server side resource watching is actually a serious motivation here.
This would help get rid of the last usage of the old storage actor (which also keeps running setupInParent and ultimately client side target switching).
But to do that we need a hack just for web extension.
As we have a unique target, with a fixed and surprising browserId/browsingContextID (related to the devtools browser element),
we have to ensure that all resources are emitted via these IDs, otherwise the ResourceCommand wouldn't be able to match the target front.
Differential Revision: https://phabricator.services.mozilla.com/D99099
With the negative margin, some context menus that remain open start
getting events that would otherwise go to the content underneath
(and which the affected tests need to pass).
Close the context menus explicitly in the affected tests (this is
what would usually happen if a user clicked a context menu item
anyways).
Differential Revision: https://phabricator.services.mozilla.com/D129867
This is the second and last step, to propagate the context down to the content process.
So that now, whenever we introduce a new context or add something into it,
it should be automatically made available to the whole codebase.
Differential Revision: https://phabricator.services.mozilla.com/D128491
This is only the beginning, focusing first on parent process usages.
WatcherActor still expose browserElement shortcut as it is useful in many places.
Context is kept JSON-serializable in order to later pass it through the SessionData.
Differential Revision: https://phabricator.services.mozilla.com/D128490
The changes in bug 1468476 dropped the requirement to re-validate subdocuments
but only in Nightly (controlled by the preference
browser.soft_reload.only_force_validate_top_level_document. Outside Nightly the
expected header "max-age=0" has to be kept.
Differential Revision: https://phabricator.services.mozilla.com/D129978
Currently, soft reload uses the `VALIDATE_ALWAYS` flag to not only
force revalidate the top level document, but also subresources.
This causes content to be refetched from the web even if there
are caches that are still valid and can be used.
Chrome already has such behaviour to not revalidate all resources.
Differential Revision: https://phabricator.services.mozilla.com/D122270
The highlighters weren't working in remote frame as the StyleSheetEditor
was always trying to use the top-level walker and highlighter fronts.
To fix that, we retrieve the appropriate fronts given the stylesheet
resource.
The existing test is augmented, which meant making the highlighterTestActor
slightly better.
Differential Revision: https://phabricator.services.mozilla.com/D128354
The test was reloading an iframe twice very quickly, which could cause Promise
failures as a new target is created each time (when EFT is enabled).
To fix those, we wait for the ROOT_NODE resource associated with the new target.
Depends on D129483
Differential Revision: https://phabricator.services.mozilla.com/D129484
This patch ensures that we are using the target-dedicated highlighterTestFront to
run some assertion on highlighters.
Depends on D129481
Differential Revision: https://phabricator.services.mozilla.com/D129483
When EFT is enabled, we have dedicated target highlighter actors; this patch ensures
we're retrieving those (and associated highlighterTestFront) to check that highlighters
do work in iframes.
`getNodeFrontInFrames` is modified so it copies the array we pass to it, as it
performs some mutation on it, and the callsite might use it later.
Depends on D129386
Differential Revision: https://phabricator.services.mozilla.com/D129481
The test had comments and disabled assertions to work around Bug 1725547.
When EFT is enabled, the issue is fixed, so the test was failing.
This patch modifies the tests to add some branches when EFT is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D129386
Fixes the leaks of the cached stacktrace info in stackTraceInfoByActorID.
Prior to this fix, the stacktrace info in the cache is only removed when the stacktrace
details panel is opened, meaning if the details panel is never opened the
info is never cleared and leaks.
This fixes the netmonitor and the webconsole as they both use the data provider
### Leak Info
#### Netmonitor
Before: 151 leaked objects (14611 with missing allocation site) in the parent process
After: -111 leaked objects (14150 with missing allocation site) in the parent process
#### Webconsole
Before: 271 leaked objects (13996 with missing allocation site) in the parent process
After: 1 leaked objects (13810 with missing allocation site) in the parent process
Differential Revision: https://phabricator.services.mozilla.com/D128015
Depends on D128991
I was wrong about 2 cache storage tests in D128866.
I thought the issue was realted to the proxy bug, but I simply had forgotten to update 2 urls ...
Differential Revision: https://phabricator.services.mozilla.com/D129184
Fixes the leaks of the cached stacktrace info in stackTraceInfoByActorID.
Prior to this fix, the stacktrace info in the cache is only removed when the stacktrace
details panel is opened, meaning if the details panel is never opened the
info is never cleared and leaks.
This fixes the netmonitor and the webconsole as they both use the data provider
### Leak Info
#### Netmonitor
Before: 151 leaked objects (14611 with missing allocation site) in the parent process
After: -111 leaked objects (14150 with missing allocation site) in the parent process
#### Webconsole
Before: 271 leaked objects (13996 with missing allocation site) in the parent process
After: 1 leaked objects (13810 with missing allocation site) in the parent process
Differential Revision: https://phabricator.services.mozilla.com/D128015
This is the second and last step, to propagate the context down to the content process.
So that now, whenever we introduce a new context or add something into it,
it should be automatically made available to the whole codebase.
Differential Revision: https://phabricator.services.mozilla.com/D128491
This is only the beginning, focusing first on parent process usages.
WatcherActor still expose browserElement shortcut as it is useful in many places.
Context is kept JSON-serializable in order to later pass it through the SessionData.
Differential Revision: https://phabricator.services.mozilla.com/D128490
Depends on D128865
For the storage inspector , most tests were migrated to https with notable exceptions:
- some cache tests checking a status (blocked on the proxy issue described at Bug 1733420)
- some tests are explicitly using mixed http/https via the test page devtools/client/storage/test/storage-listings.html
Differential Revision: https://phabricator.services.mozilla.com/D128866
We weren't removing listeners on the target actor,
and also some late DOMContentLoaded/load event may be fired.
We were getting exception because of late events when closing the toolbox on a still-loading page.
Differential Revision: https://phabricator.services.mozilla.com/D129056
This is one step forward removing target attach sequence on the client side.
So that we can notify about target front immediately from TargetCommand.
I had to tweak TargetMixin destroy to avoid failures in browser_dbg_listtabs-01.js
a call to targetFront.reconfigure was never resolving, because the target destroy
was stuck on this call to detach().
We were trying to call detach() while the descriptor was destroyed (from a server side notification).
The target being a child of descriptor it ends up destroy itself, but the request is meant to fail.
Depends on D118585
Differential Revision: https://phabricator.services.mozilla.com/D118586
This depends on calling startListening, which forces target to be attached asynchronously.
Also, we would like to stop calling startListening as it has been replaced by watchResources APIs.
If we ever need a trait, we should rather use RootActor one,
as it is easy to read by any code. Or we should come up with something
more robut and more generic that this startListening setup.
Depends on D118584
Differential Revision: https://phabricator.services.mozilla.com/D118585
The toolbar pref change triggers eventually a look-and-feel-changed
notification, so no need to observe that directly.
Depends on D128674
Differential Revision: https://phabricator.services.mozilla.com/D128675
The base patch updated the behavior of document.requestStorageAccess to require user activation and moved the user activation check to the top of the method.
To test for the other rsA error messages, which are in the user activation guarded parts of the method, we need to simulate user activation.
Requiring user activation also means we should not run the rsA requests in parallel to avoid side effects.
Differential Revision: https://phabricator.services.mozilla.com/D128106
Reenable https-first for the test now that example.net can be used with HTTPS
Also add URL_ROOT_NET_SSL to the shared-head shortcuts
Differential Revision: https://phabricator.services.mozilla.com/D128414
This patch helps fix browser_grids_grid-list-on-target-added-removed.js when applying previous patches of this queue.
Slightly delay the precise timing when we emit target-destroyed.
This introduce a race condition in getAllFronts, which most likely cache
a list of target fronts before receiving the target-destroyed event,
then process the top level target asynchronously,
then try to process the iframe target which has been destroyed in the meantime.
Trying to call TargetFront.getFront on this destroyed target throws
and ultimately break the grid inspector which will reset its view from GridInspector._updateGridPanel.
Differential Revision: https://phabricator.services.mozilla.com/D128346
browser_target_command_frames.js covers explicit destruction order of iframes and started failing
because of the code to delay target-destroyed to be fired *after* will-navigate for top targets.
Differential Revision: https://phabricator.services.mozilla.com/D128091
By matching via BrowsingContext's ID, we can match the next Target Front,
of the page we navigate to. That, instead of matching the previous Target Front,
of the page we navigate from.
Using innerWindowId allows to match a unique target actor/front.
(It help fix browser_aboutdebugging_devtoolstoolbox_navigate_back_forward.js and browser_webextension_inspected_window.js)
Differential Revision: https://phabricator.services.mozilla.com/D127773
These IDs should be fixed to the top level WindowGlobal that the target is debugging.
We somewhat fake changing to another WindowGlobal to implement the iframe dropdown
(via WindowGlobal.setWindow) but this is only transient and doesn't change
the fact that the current target actor is meant to debug its original top level WindowGlobal.
Not doing this confuses the TargetCommand which is trying to look for a target actor
for the iframe we switched to, which doesn't exists as it doesn't have any specific target actor.
Differential Revision: https://phabricator.services.mozilla.com/D127776
Otherwise, it may be null if we query this attribut in between target instantiation and the time we attach it.
(Note that browser_inspector_iframe-picker-bfcache-navigation.js covers this)
Differential Revision: https://phabricator.services.mozilla.com/D127775
Without this many tests start failing when we start using innerWindowId to match targets.
Because will-navigate's target front is destroyed before the frontend
process DOCUMENT_EVENT's will-navigate.
(It helps fix browser_aboutdebugging_devtoolstoolbox_navigate_back_forward.js and browser_webextension_inspected_window.js)
Differential Revision: https://phabricator.services.mozilla.com/D127772
