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
Iulian Moraru
Dana Keeler
Henrik Skupin
Jan Odvarko
Oriol Brufau
Claudia
Gerald Squelart
Cristian Tuns
Hubert Boma Manilla
Norisz Fay
Alexandre Poirot
Nicolas Chevobbe
Emilio Cobos Álvarez
Marian-Vasile Laza
Neil Deakin
Randell Jesup
James Graham
Kershaw Chang
Greg Tatum