As for the console, we don't really have to pass a context as we always
navigate in the foremost tab. We would need to pass a context if the tab was in background.
Differential Revision: https://phabricator.services.mozilla.com/D62807
--HG--
extra : moz-landing-system : lando
See the first bug's changeset, we don't really need a context, but only the URL.
I choose "navigateTo" name as it aligns with other existing helper and the method on the Target actor.
Differential Revision: https://phabricator.services.mozilla.com/D62805
--HG--
extra : moz-landing-system : lando
The netmonitor may benefit from a custom helper to open the netmonitor and navigate to an URL
as the current code forces a bit of duplication between each test.
Differential Revision: https://phabricator.services.mozilla.com/D62804
--HG--
extra : moz-landing-system : lando
This is meant to support all needs we have when navigating to a new document,
while a toolbox is opened. When you don't have one, you should fallback
to BrowserTestUtils helpers.
It looks like, we never navigate in a background tab, so there is no need
to pass a `browser` element. We may introduce an optional argument if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D62803
--HG--
extra : moz-landing-system : lando
Since both operators are now supported in Firefox,
we should make sure we can use them in top-level
await expression in the console.
Unit tests are added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D63043
--HG--
extra : moz-landing-system : lando
Part 1: Only show Waterfall only for visible rows: IntersectionObserver
collects which rows are off screen as state. New elements register with
the list observer and unregister later. Waterfall column is only
rendered for visible rows and just an empty TD for the rest.
Part 2: Scale Waterfall without transform: Waterfall isn't handled by
CSS variables anymore (expensive styling fix).
Differential Revision: https://phabricator.services.mozilla.com/D58476
--HG--
extra : moz-landing-system : lando
The default preset is "web-developer", and the DevTools panel was using that
preset over the custom values until at least one value was tweaked. This patch
changes the UI to only use the "custom" preset when in the DevTools panel. This
panel code will all be removed soon, so this is only a migration step.
Differential Revision: https://phabricator.services.mozilla.com/D62956
--HG--
extra : moz-landing-system : lando
Part 1: Only show Waterfall only for visible rows: IntersectionObserver
collects which rows are off screen as state. New elements register with
the list observer and unregister later. Waterfall column is only
rendered for visible rows and just an empty TD for the rest.
Part 2: Scale Waterfall without transform: Waterfall isn't handled by
CSS variables anymore (expensive styling fix).
Differential Revision: https://phabricator.services.mozilla.com/D58476
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
The 'getter button' wasn't working correctly on root level items in the preview popup.
A check is added on root item to see if it has any corresponding evaluation result,
and if so take that value instead of the original one.
A test is added to ensure that the button now works on those top-level elements in
the preview popup.
Differential Revision: https://phabricator.services.mozilla.com/D61086
--HG--
extra : moz-landing-system : lando
Doing this helps ensuring that all async work done in panels,
when attaching to the top level target, to fetch already existing resources,
is fully completed before the test ends.
Differential Revision: https://phabricator.services.mozilla.com/D62554
--HG--
extra : moz-landing-system : lando
First simple attempt at fixing this. The target getter in the DOM panel already
refers to the current toolbox top-level target. There doesn't seem to be a need
to change this as this is the only target the DOM panel cares about.
So, I'm only adding a listener for new top-level targets and refreshing the
panel when that happens, just like we do on navigation.
Am I missing something?
Differential Revision: https://phabricator.services.mozilla.com/D60013
--HG--
extra : moz-landing-system : lando
While making the change in the previous patch (to make the dom panel use
the targetList API), and writing a test for it, I stumbled upon a weird
issue that I don't think we've encountered so far.
The console's actor method evaluateJSAsync does things a bit differently
than other methods. It spawns the work it needs to do, but does not wait
for it to be done, and immediately returns an ID to the client.
Later, when the work is done, it sends an event back to the client with
the response.
It's then up to the client to use the ID provided in the immediate response
and match it against the incoming event to verify that this is, indeed,
the right response.
In all cases we've seen so far, the event comes back after the initial
method response. This seems logical as evaluateJSAsync uses an
executeSoon helper to spawn the work needed in the next event loop.
Now, the case I have seen as witnessed by the test I added is that,
sometimes, the event actually comes back before the initial response.
Because both things go through the protocol.js message handling, and
because all of it is asynchronous, it may indeed happen. There's no
guaranty at the protocol level to avoid this.
So, my approach here is to simply avoid this to happen from the client
side. I don't think we should be doing a generic fix in protocol.js for
this, but instead clients should be prepared for these things to happen.
Differential Revision: https://phabricator.services.mozilla.com/D62417
--HG--
extra : moz-landing-system : lando
If the CSS filter was enabled, when the user would navigate to a page
on a different origin, the CSS Warnings from the new page wouldn't
be displayed in the console.
This is related to how we manage the CSS Warnings. Since emitting those
messages is costly, we only do so when the console is opened, if
the user already set the filter, or when they turned it on.
The issue is that it was only done on the main target, and only
when the console would start, or when the user clicked on the css
filter button.
So with Fission enabled, we could switch to a new target, but we
wouldn't trigger the code that parses the stylesheets of the new
page.
The browser_webconsole_message_categories was asserting this issue,
and is now fixed (after setting the proper target switching target).
Differential Revision: https://phabricator.services.mozilla.com/D61558
--HG--
extra : moz-landing-system : lando
This adds the pref to the browser_webconsole_inspect_cross_domain_object.js test.
The test was modified a bit to not navigate, otherwise we don't get the connection
to the target iframe.
Differential Revision: https://phabricator.services.mozilla.com/D61560
--HG--
extra : moz-landing-system : lando
This patch sets the pref for tests where it's needed (often
when the test navigates from an origin to another).
When possible, the skip-if=fission tag is removed.
For remaining issue, referencing to the bug where we should
re-enable those tests.
Differential Revision: https://phabricator.services.mozilla.com/D61559
--HG--
extra : moz-landing-system : lando
The function is changed to detect if we're going to navigate to
a different origin, and if fission and target switching are enabled,
will wait for the switched-target event to ensure devtools are
fully ready after a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D62413
--HG--
extra : moz-landing-system : lando
The id was retrieved by transforming the map into an array
and getting the last element of it. This was slow and
allocatiing a lot of memory when the messages Map contained
a lot of elements.
This patch make it so we're now storing the last message
id directly in the state so we can get it in a cheaper way.
Differential Revision: https://phabricator.services.mozilla.com/D62185
--HG--
extra : moz-landing-system : lando
Refactored CookiesPanel and PropertiesView to use the shared Accordion. Created request-details/ for the new files.
Removed the old CookiesPanel. Fixed one cookie failing test, by removing the headings which are no longer part of the tree.
Differential Revision: https://phabricator.services.mozilla.com/D62200
--HG--
extra : moz-landing-system : lando
The autocomplete popup does a case-insensitive match, so
some items could end up changing the final input value.
This is already handled when selecting an autocomplete item,
but it wasn't the case for the eager evaluation.
This patch moves the code of the acceptCompletion function
to another function, that we can then call from the eager
evaluation updates.
Differential Revision: https://phabricator.services.mozilla.com/D62553
--HG--
extra : moz-landing-system : lando
Before now, we used XUL elements as the menu for device selection on RDM.
We introduced the icon on the XUL menuitem in bug 1306198, but the UI on Ubuntu
became weird looking. In order to fix this, we could think to modify Linux
gadget, but we replace to HTML menu components we are using in DevTools with
considering deXUL as well.
Differential Revision: https://phabricator.services.mozilla.com/D61149
--HG--
extra : moz-landing-system : lando
We don't actually share _that_ much code across them. This makes callers clearer
and code less confusing, IMHO.
This also has the benefit of not autocompleting path from devtools for
shape-outside.
Differential Revision: https://phabricator.services.mozilla.com/D62373
--HG--
extra : moz-landing-system : lando
This test isn't ready to be run on all versions of Firefox yet. It is
part of the suite of changes for the new about:profiling workflow.
Differential Revision: https://phabricator.services.mozilla.com/D62458
--HG--
extra : moz-landing-system : lando
The JsPropertyProvider parser is modified to accept optional chaining
syntax.
Differential Revision: https://phabricator.services.mozilla.com/D60654
--HG--
extra : moz-landing-system : lando
The filterbar grid should only have subgrid for grid-template-rows,
not columns, as we want it to have its own column (1 for the main
ui elements, and another one for the close button).
Differential Revision: https://phabricator.services.mozilla.com/D61859
--HG--
extra : moz-landing-system : lando
Identifying the function calls and marking them is the first step for adding the feature 'command click should jump to function call'.
Steps to see the function call marks:
1. Pause the debugger.
2. Press command key. (Function calls are highlighted in blue).
Differential Revision: https://phabricator.services.mozilla.com/D52390
--HG--
extra : moz-landing-system : lando
Removed part of// devtools-reps/src/object-inspector/actions.js// as suggested in the patch D61086
Differential Revision: https://phabricator.services.mozilla.com/D62049
--HG--
extra : moz-landing-system : lando