Much like devtools manages the existing stylesheet changed events.
This is tested by devtools/client/inspector/markup/test/browser_markup_shadowdom.js
Differential Revision: https://phabricator.services.mozilla.com/D102875
We used to not do anything on navigation for the error count
at the toolbox level, but the test we had to check that the
count was reset on navigation was working; this is because
there's a hook in the console panel to clear the error count
when the console is cleared, and in the test, the console panel
was selected.
This patch fixes that and adds a new test that run some assertion
on reload, without ever enabling the console panel.
Since some assertions seem redundant with the test we already had,
we remove them from the old test.
Differential Revision: https://phabricator.services.mozilla.com/D102325
This handles most of the localization, but will require a few follow-ups.
First off is Bug 1681539, which is for localizing profiler presets. There
isn't anything too weird about this for the DevTools and about:profilling
context, but requires a solution for the popup. The appmenu.ftl bundle
might need to be included.
I did not localize profiler feature list, nor the byte size computation.
Differential Revision: https://phabricator.services.mozilla.com/D99275
The two "location" expressions being added, removed and re-added
are mixed up in the UI if we don't wait for the evaluation of the first,
before removing and re-adding it.
Differential Revision: https://phabricator.services.mozilla.com/D102323
This is the simple step, where we move the ThreadFront code related to pauses
from Debugger frontend to a legacy listener.
The next patch is the hard one, which will replace paused/resumed events by resources.
It may sound weird to have pause and resume to becomes resources,
as they aren't really resources. These are transcient events, which we don't
really want to record. We especially do not really care to save them in the ResourceWatcher cache.
But, by becoming resources, we benefit from the resources framework, which allows to:
* listen and emit such event as early as the page/target starts loading
* do not depend on a particular front to be ready/attached on the frontend
* once we communicate to the watcher we care about breakpoints, we do register the breakpoint listening code for all the targets.
(we no longer have to do a per-target work in the frontend)
Differential Revision: https://phabricator.services.mozilla.com/D88851
Since about:blank gets spawned in the same process when included in a frame, it was being added as a host for the top page in content process storage resources. This patch removes about:blank from the `windows` list unless it is the top level page itself.
Differential Revision: https://phabricator.services.mozilla.com/D96029
We weren't calling preventDefault on the event handler, which was
allowing the browser to consume it, and toggle reader mode on windows,
which shares the same keyboard shortcut (F9).
A test is added to ensure we don't regress this (the test is failing without
the fix).
Differential Revision: https://phabricator.services.mozilla.com/D101919
We weren't calling preventDefault on the event handler, which was
allowing the browser to consume it, and toggle reader mode on windows,
which shares the same keyboard shortcut (F9).
A test is added to ensure we don't regress this (the test is failing without
the fix).
Differential Revision: https://phabricator.services.mozilla.com/D101919
This exception happens quite frequently with Fission enabled as we start observing requests
while the page already start loading. This happens frequently when target switching.
Differential Revision: https://phabricator.services.mozilla.com/D101828
In `setErrorCount`, we used to call setToolboxButtons unconditionally, which means
that it was called each time a resource was added or updated.
This was very expensive and would cause some slowness, especially on pages with
a lot of network requests, as revealed by DAMP tests.
In this patch, we don't call setToolboxButtons if the error count did not change.
On top of that, we add a throttle mechanism so the function can't be called more
than twice per second.
Differential Revision: https://phabricator.services.mozilla.com/D102136
The test used to fail after navigating because the expected property
wasn't displayed.
Here we're trying to work around that by:
- using the navigateTo helper function, which takes care of waiting for the right events
- awaiting until the property is displayed (since it wasn't before), just in case the
rendering takes more time than expected.
Differential Revision: https://phabricator.services.mozilla.com/D101783
A button configuration is now created from _buildButtons so the error count button
is part of the `toolbarButtons` property on the toolbox.
An `updateErrorCountButton` updates the property of the button, and we call it
from the function that updates the error count, from which we also trigger a new
render for the toolbar.
This way updating the error count will go through the overflow logic we have in
the toolbar (to show the chevron or not).
A "side effect" of this is that an item is automatically created in the options
panel to disable the error count button. In order for it to work properly, we
need to add a preference to store its enabled state, as well as a specific
localized string for the input label.
browser_toolbox_error_count is updated to ensure that the error button isn't
displayed if it was disabled in the option panel, even if new errors are emitted.
browser_toolbox_options_disable_buttons was updated to reflect the changes made
to the error count button.
Differential Revision: https://phabricator.services.mozilla.com/D101569
- switch to add_task + registerCleanupFunction
- reorder functions so they match the order they're called in the main function
- remove global variables in favor of explicit parameters
- switch from Promise chains to await where possible
Differential Revision: https://phabricator.services.mozilla.com/D101568
Stop unregistering onExceptionUnwind on navigation (will-navigate) and pauses.
So that we no longer have to re-register it on window-ready and resume.
Instead, only check that we aren't paused when processing an exception.
Regarding navigation, I don't think we want to ignore any exception during the process of navigating to another page.
I would rather say we want to catch anything that happen during this process!
Differential Revision: https://phabricator.services.mozilla.com/D101651
This patch modifies and renameGeneratePureDOMFunctions.py so it generates a new file
indicating all the deprecated properties and methods so we can retrieve those information
in DevTools, in order, for example, to not call those deprecated properties and avoid generating
warning messages.
Differential Revision: https://phabricator.services.mozilla.com/D80864
At the moment, the ObjectInspector, while having its own reducer and actions, has its
state located in the state of its consumer application (e.g. webconsole, debugger).
This patch, by adding a `standalone` prop to the ObjectInspector, will allow the said
consumer to not have the object inspector state shared anymore.
This makes interaction in a given objectInspector much faster as only one instance
will have its lifecycle methods triggered. It also prevent cloning the consumer's state
on each object inspector interaction.
This new props is only used in the webconsole for now, as the debugger might need
to have access to its objectInspector state (this is also less of a problem, because
the debugger won't hold that much instances at a given point in time, unlike the console).
The DAMP data seems to indicate a 40% improvement in the console when expanding
an object while there are a thousand instances in the console.
Differential Revision: https://phabricator.services.mozilla.com/D99472
This patch adds a shared-node-helper function that, for now,
exposes a single setMocksInGlobal function. This function
adds node global missing apis (e.g. requestAnimationFrame, indexedDB, ...),
and is called from the different node setup files, than can then be cleaned up.
For some reason, a debugger test had to be updated to pass.
Differential Revision: https://phabricator.services.mozilla.com/D99471
This creates a new devtools/client/shared/test-helpers folder in which we add
a share jest config, which define a `moduleNameMapper` option with all the
different fixtures that were used in the codebase.
The fixtures were moved from different panels to a jest-fixtures folder and
the one that were left unused are removed.
Some fixtures file needed to be modified to satisfy eslint rules.
Differential Revision: https://phabricator.services.mozilla.com/D99470
Retrieve the target in which the selected node lives in order
to get the right screenshotFront.
There was already a test checking that taking a node in an iframe was working,
but it was a same-origin iframe.
We modify the test so it checks both same-origin and remote iframe.
Differential Revision: https://phabricator.services.mozilla.com/D101438
The `waitUntilScreenshot` wasn't waiting for a new screenshot to be taken, and
if a test took 2 screenshots, it would always return the first one. This is
fixed by managing an array of the downloads we already waited for.
The test was also assuming the dpr of the screen was always 1, which was making
the test fail when running on a machine with a higher dpr screen (e.g. a retina screen).
The assertion for the width and height are updated to take dpr into account.
Differential Revision: https://phabricator.services.mozilla.com/D101437
Without this, we were silently ignoring many errors when evaluating a piece of JS.
Imported function may still work, but were missing global variables. Very misleading!
Differential Revision: https://phabricator.services.mozilla.com/D100927
We need to use the same technique as in watchResources in order to ensure
reaching out the top level targets running in the parent process...
Differential Revision: https://phabricator.services.mozilla.com/D100926
Depends on D100564
This patch updates test which deal with swatches for toggling a CSSGridHighlighter from the Rules view. This is similar to changes made for FlexboxHighlighter tests in D96225.
The changes are straightforward:
- replace the class name of the toggle: `.ruleview-grid` → `.js-toggle-grid-highlighter`
- use generic test helpers for highlighters: `waitForHighlighterTypeShown`, `waitForHighlighterTypeHidden`
NOTE: To reviewers: I won't be able to address code review comments. Please commandeer, update, and land this patch yourself.
Differential Revision: https://phabricator.services.mozilla.com/D100565
Depends on D100563
Following the example introduced for FlexboxHighlighter in D96225, this patch updates the state of the swatch to toggle the CSSGridHighlighter from the Rules view in response to corresponding highlighter events.
NOTE: To reviewers: I won't be able to address code review comments. Please commandeer, update, and land this patch yourself.
Differential Revision: https://phabricator.services.mozilla.com/D100564
This patch is following the precedent introduced for FlexboxHighlighter in D96225 to delegate click event handling to the Rules view and toggle the CSSGridHighlighter from there (moving out of HighlightersOverlay). It introduces a new class name to designate the toggle element, `js-toggle-grid-highlighter`, independent from class names used for styling.
Patches later in this series update the corresponding tests.
NOTE: To reviewers: I won't be able to address code review comments. Please commandeer, update, and land this patch yourself.
Differential Revision: https://phabricator.services.mozilla.com/D100563
Butkovits Atila
Emilio Cobos Álvarez
Dimi Lee
Daisuke Akatsuka
Gerald Squelart
Brindusan Cristian
Sebastian Zartner
Hubert Boma Manilla
Nicolas Chevobbe
Jared Wein
Greg Tatum
Yura Zenevich
Mihai Alexandru Michis
Julian Descottes
Alexandre Poirot
Florian Quèze
Belén Albeza
Abhishek Sharma
Masatoshi Kimura
Steven MacLeod
Noemi Erli
longsonr
Markus Stange
Micah Tigley
Mark Banner
Tim Nguyen
Falguni Islam
Razvan Caliman
pedrofonsecadev