The function was returning true as long as the passed element
was an iframe and EFT was enabled.
But if the passed iframe was blocked by a CSP rule, it would
still return true, although we wouldn't actually have a dedicated
document, nor a target, for that iframe, which would lead to
issues in the inspector when trying to fetch the iframe children.
We fix this by adding a new `isFrameBlockedByCSP` util, which uses
`nsIContentPolicy#shouldLoad` with the iframe url so we can check if the iframe
is blocked by CSP, and in such case, return false.
We're also using this new function in the `NodeActor#form` method to set a `numChildren`
of `0` when the iframe is blocked (so in the inspector, the expand icon will be
hidden for the element), as well as in `WalkerActor#_getChildren` to return an
empty array when called with an iframe blocked by CSP.
A new test is added to check the iframe nodeFront properties and usage of
`WalkerFront#children` with those. We allow to set a specific pref to bypass
the guard in the children method in order to properly check that the root issue
of a given bug was fixed.
Differential Revision: https://phabricator.services.mozilla.com/D137667
This can be seen as a hot fix for Bug 1752342. Here we're not fixing the
root cause of the issue, but rather adding a protection mecanism so we don't
completely crash/freeze the inspector/the browser.
A follow-up bug will take care of Bug 1752342.
Differential Revision: https://phabricator.services.mozilla.com/D137450
Check if ownerRule.layerName is null, rather than checking
the property exists.
A test case is added in browser_rules_layer.js.
Differential Revision: https://phabricator.services.mozilla.com/D137447
In order to make it more clear what the browser icons mean in the compatibility
panel, we move the title attribute that was set on individual browser icon to
the browser icon list instead, in which we put the full list of unsupported
browser (with their name and version), prefixed with a "Compatibility issues in:"
label.
Differential Revision: https://phabricator.services.mozilla.com/D137004
About:debugging seems to be the only consumer of the tabListChanged event at this point.
One of the internal events used by about:debugging was not properly handled. Added a minor fix to change that and added a new mochitest for about:debugging.
Differential Revision: https://phabricator.services.mozilla.com/D137293
This link has not been working for a while, switching to an MDN example page.
We should still come up with example pages hosted on a domain owned by devtools team if possible
(and not on the personal github account of a team member :) )
Depends on D137141
Differential Revision: https://phabricator.services.mozilla.com/D137282
Guard `Toolbox#updateFrameButton` with `isDestroying` so the call to `this.target`
later in `_commandIsVisible` doesn't throw because `this.commands` is null.
Differential Revision: https://phabricator.services.mozilla.com/D136713
This patch introduce a new test helper to more easily test a page that reloads with an updated content.
This especially take care of source map support.
Differential Revision: https://phabricator.services.mozilla.com/D137162
As we are already filtering the JS Globals via _shouldAddNewGlobalAsDebuggee,
there is no need to filter out the JS Sources.
We do want all the sources for all the WebExtension globals.
Differential Revision: https://phabricator.services.mozilla.com/D136507
This ensures @media and @layer information can be searched for and properly highlighted
in the rule view.
A test is added to check various cases.
Differential Revision: https://phabricator.services.mozilla.com/D137107
We are fixing mochitests that fail when network.cookie.cookieBehavior = 5, i.e. when we enable Total Cookie Protection.
This is most often due to the test assuming that an origin will always have access to its storage state when embedded as
a third party.
My approach: Add third-party storage permission for the net domain when included on the com domain.
This allows the cache for the net domain to be shared in the way that this test is expecting.
Differential Revision: https://phabricator.services.mozilla.com/D136601
We don't need to have specific check for dom0 event listeners as the debugger
button should be show as long as we managed to create a source actor.
We can remove usage of `script.source.element` alltogether as we don't need
it for not showing the line number in the location (the line is 0 in such case,
and we already discriminate for such value).
A test case is added to ensure that the debugger can be opened from the
event tooltip on a dom0 event.
Differential Revision: https://phabricator.services.mozilla.com/D136461
This is only an issue when devtools.popups.debug is false,
when it is true, the toolbox is move and a warning message is printed
if we request to open a new toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D136498
We were missing cached image request and probably CSP blocked request
from the parent process because of this.
We are spawning a NetworkEventContentWatcher for the parent process target.
That's semi-intentional. This might better be done via a parent process resource type,
like NETWORK_EVENT. But the current Resource framework doesn't allow to do that easily.
So that we currently spawn the NetworkEventContentWatcher (and NetworkEventStackTraceWatcher)
against the parent process target actor as a "FRAME" resource type.
This is handy as we need at least one of these two watchers for the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D136325
It was only used in storeExpressions, where we can replace it by storing only the input property
instead of removing the value property from the object we store.
Differential Revision: https://phabricator.services.mozilla.com/D136164
test_stepping-12.js wasn't correctly waiting for thread to be resumed between each of its sub test.
Similarly, other tests weren't waiting for thread front's resume request to be resume.
I'm also spreading the usage of resumeAndWaitForPause to better ensure we resume and wait for next paused event
without any race condition. Listening to "paused" after calling "resume" is subject to race conditions.
Differential Revision: https://phabricator.services.mozilla.com/D136125
If a test involving the Browser Toolbox times out, the Browser Toolbox
would not close and could have impact on next tests.
In this patch we register a cleanup function to make sure we always
close the Browser Toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D136096
We take this opportunity to rename `removeInnerLocations` to `getInnerLocations`
and make it return an array of inner locations rather than returning the list
of original locations with inner locations stripped.
This makes the function easier to understand (not having to deal with indexes
+ splicing), and doesn't harm the only callsite where we can handle those inner
locations into the filter call that was done on the array returned from `removeInnerLocations`
The parser-worker was updated.
Differential Revision: https://phabricator.services.mozilla.com/D136095
If the browser toolbox is started from a Marionette enabled process,
Marionette should never be started for the browser toolbox process.
If we do as right now the browser toolbox process will immediately
shutdown because Marionette cannot listen on the already in-use
socket port and forces a process shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D136220
This helps:
* registering blackboxing before the page starts loading.
So that blackboxing better work if we break early during the page load.
* transfert the blackboxing information only once per URL instead of once per source actor.
We now communicate the ranges once to the BlackboxingActor.
Also, we can pass a list of ranges instead of range per range.
Differential Revision: https://phabricator.services.mozilla.com/D135614
The icon is now a crossed-out file and is displayed in red.
We set the background for ignored line to a red-ish grey that will hopefully
better convey the fact that those lines are ignored.
Differential Revision: https://phabricator.services.mozilla.com/D135974
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
This will cause a new highlighter to be created when onToggleFontHighlight
is called next.
Ideally, we wouldn't have a reference to the highlighter as this is probably
not working for Fission, and we would use the HighlightersOverlay like the
other inspector panel, but that probably requires its own bug.
A test is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D135998
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
Doing this helps load resource-command module from jest tests
which were throwing when loading the transformers.
And it probably is a small performance improvement.
Differential Revision: https://phabricator.services.mozilla.com/D135719
This is also behind "devtools.popups.debug", to be set to true manually.
This special mode break the old fundamental principal where a given toolbox
is bound to one unique given tab. Now one toolbox starts being shared between
many tabs.
When we select the original tab we debug, or any of its popups opened in distinct tabs,
we will move the toolbox between each of these tabs.
We will have one toolbox instance, one toolbox iframe, which will be moved
around each tab's host. This is somewhat similar to host switching within the same tab.
This is all based on the same trick where we swap the toolbox iframe to another location.
Differential Revision: https://phabricator.services.mozilla.com/D131802
With popup debugging (next patches), we trigger a race condition in this code
where `SourcesManager.urlContents` is called *after* `devtools-html-content` is fired.
i.e. after the HTML document is parsed.
This lead to return an async promise instead of an immediate value.
This confuses `SourceActor._getStartLineColumnDisplacement` which no longer apply breakpoints right away.
We miss early breakpoint support for popups.
This isn't easy to reproduce beyond popup debugging,
in next changeset, browser_dbg-breakpoints-popup.js's testPausedByBreakpoint covers this.
Differential Revision: https://phabricator.services.mozilla.com/D135144
For now, we only do that when "devtools.popups.debug" is manually set to true.
This is introducing some complexity in the way we filter out the WindowGlobal
we should consider or not. Before this patch it was quite straightforward.
We accepted all WindowGlobal's matching the tab's `browserId`.
Now we also accept the WindowGlobal whose `opener`'s `browserId` matches.
With this patch only, popups start appearing in the iframe dropdown.
You still have to manually switch to the popup via the dropdown to debug it in the inspector or console.
In the debugger, you will already start seeing the popup source and break on it.
Differential Revision: https://phabricator.services.mozilla.com/D133350
This patch adds a checkbox at the end of each event listeners in the EventTooltip,
which allow the user to disable/re-enable a given event listener.
This is done by managing a Map of nsIEventListenerInfo object in the NodeActor,
which we populate from `getEventListenerInfo`. Each `nsIEventListenerInfo` is
assigned a generated id, which can then be used to call the new NodeActor
methods, `(enable|disable)EventListener`.
We don't support disabling jquery/React event listeners at the moment, so we
display the checkbox for them as well, but disabled.
Differential Revision: https://phabricator.services.mozilla.com/D135133
This patch adds a checkbox at the end of each event listeners in the EventTooltip,
which allow the user to disable/re-enable a given event listener.
This is done by managing a Map of nsIEventListenerInfo object in the NodeActor,
which we populate from `getEventListenerInfo`. Each `nsIEventListenerInfo` is
assigned a generated id, which can then be used to call the new NodeActor
methods, `(enable|disable)EventListener`.
We don't support disabling jquery/React event listeners at the moment, so we
display the checkbox for them as well, but disabled.
Differential Revision: https://phabricator.services.mozilla.com/D135133
Unfortunately, I haven't find any useful attribute on JSWindowActorChild/WindowGlobalChild/BrowsingContext
to detect that things are destroyed, or to be destroyed and avoid calling sendAsyncMessage,
or detect in the exception handler that we got destroyed.
So I'm falling back to ignore the exception based on its message...
Differential Revision: https://phabricator.services.mozilla.com/D135608
In the Browser Console, document-event resources are retrieved from a
legacy listener built on top of the documentEvent event, sent by the
webconsole actor.
documentEvent wasn't including hasNativeConsoleAPI, and we were displaying
a misleading overriden console API message there.
This patch fixes this and adds a test case to make sure we don't regress.
Funnily, the mochitest test harness _does_ override the global's console
property, and we have to reset it in the test to make sure the warning message
is not displayed.
Differential Revision: https://phabricator.services.mozilla.com/D135585
Track all code which may filter BrowsingContext or WindowGlobal in the server codebase
in order to use a unique filtering method.
Differential Revision: https://phabricator.services.mozilla.com/D134423
Popup debugging (bug 1569859) will force to revisit how we filter out the BrowsingContext
that are meant to be debugged. We won't only accept BrowsingContext based on their browserId.
This would force us to carefuly review all the codes where we filter BrowsingContexts.
And if we later have to tweak this, do this again.
It would be nice to have a unique method to filter things out.
It will also be beneficial once we add new debuggable contexts like workers
as we would only have to tweak this method.
For now, this patch focuses only on Target helpers and JSWindowActor's,
but I'll followup to other server modules.
Note that I'm changing the behavior of getAllRemoteBrowsingContexts
in order to also return the top browsing context by default.
We were having a few places where we were re-adding it after,
but that's not trivial. It is easier to remove it in the rare function that need that.
Differential Revision: https://phabricator.services.mozilla.com/D134422
This boolean helps know for which BrowsingContext we should create a target or track resources.
So that it is part of what defines the context we should debug and will be handy to have
in all filtering functions we use to filter browsing context or platform objects.
Differential Revision: https://phabricator.services.mozilla.com/D134421
This commit adds support for setting the pseudo-locale for the browser
UI directly from the Browser Toolbox. This places the icons in the same
place as the "Disable Popup Autohide" command. This will make it easier
for Firefox developers to test that their UI is properly localized.
The SVGs were optimized for size using an optimizer that dropped the
path precision and any extra tags. I tested that they work correctly in
both light and dark modes.
Pseudo-localization is documented here:
https://firefox-source-docs.mozilla.org/l10n/fluent/tutorial.html#pseudolocalization
After this patch lands I'll follow-up with updating that documentation.
Differential Revision: https://phabricator.services.mozilla.com/D134420
In target-actor-mixin, we were calling `setActiveEventBreakpoints` only with the
new events we were receiving, which mean if the user was clicking a first event in
the UI, and then a second one, only the second one would have a functioning event breakpoint.
Also, we were not handling removing event breakpoints at all.
We're adding `(add|remove)EventBreakpoints` to the thread actor so it's easier
to update the list of event breakpoints.
The existing event breakpoints test is modified to ensure we don't regress such behaviour.
The call to `setEventListenerBreakpoints` is moved before dispatch the `UPDATE_EVENT_LISTENERS`
action so we can properly wait for the breakpoint to be set in tests.
Differential Revision: https://phabricator.services.mozilla.com/D135216
"original" here refers to not being generated.
It overlaps with pretty printed sources, which are considered as original sources.
Differential Revision: https://phabricator.services.mozilla.com/D134751
And better document all types of source objects:
* generated
* source map original sources
* pretty printed sources
As well as source object attributes!
Differential Revision: https://phabricator.services.mozilla.com/D134786
Avoids using context menu, affected by bug 1478596, so that the test can be
re-enabled in Linux WebRender.
Replaces deprecated OS.File with IOUtils.
Adds try..catch as an attempt to investigate timeouts like bug 1650268.
Adds some extra checks, and some refactorings.
Differential Revision: https://phabricator.services.mozilla.com/D135146
parentMap appears to only be used when pressing the left arrow key to navigate
to the parent folder in the source tree. If this is too slow it could be
replaced with a traverseTree search.
Differential Revision: https://phabricator.services.mozilla.com/D115318
The information it provides is unclear and I don't see how this could be valuable.
We take this opportunity to move the tags before the "capturing" label to get
better alignment between mixed events (e.g. regular and React ones).
Differential Revision: https://phabricator.services.mozilla.com/D135130
- Remove `NodeActor#getEventListeners` which was simply a proxy to `EventCollector#getEventListeners`
- Change signature of `EventCollector#processHandlerForEvent` to make code easier to follow
Differential Revision: https://phabricator.services.mozilla.com/D135128
The function was only creating an EventTooltip instance, so we can directly modify
the only call site to do the same thing.
Since the EventTooltip isn't responsible for showing the tooltip itself, and given
that the consumer code already does some work when the tooltip gets hidden, we
let the consumer call EventTooltip#destroy instead of having the EventTooltip
register the event listener on the tooltip.
Differential Revision: https://phabricator.services.mozilla.com/D135127