For iframes it's important that we use the correct storage principal when interacting with cookies.
With dFPI enabled the origin attributes of third party contexts are different from the top ones.
This led to situations where we didn't show any cookies for storage isolated third party frames.
Differential Revision: https://phabricator.services.mozilla.com/D99439
This way we ensure that any microtask created by the evaluated expression are
run, which can impact what we send to the client (e.g. `Promise.resolve().then(() => 246)`
will show a resolved promise instead of a pending one).
Some stubs and node tests are added to ensure this does fix the issue.
Differential Revision: https://phabricator.services.mozilla.com/D100979
The test was failing on the getFileContents, where the channel we're using here
would close for some reason.
In this patch, we no longer create a channel but use OS.File.read to retrieve the
content of the saved file.
We take this as an opportunity to slightly refactor the test so it's easier to read.
Differential Revision: https://phabricator.services.mozilla.com/D101147
This allows supporting image-set(), etc, and simplifies the bullet frame
code significantly, too thanks to two changes:
* Instead of manually managing the image request, use the CSS image
loader, with the `REQUEST_REQUIRES_REFLOW` flag, to handle image
loads correctly. This didn't exist when this code was initially
implemented, but we can nicely use it now.
* Instead of re-implementing another WebRender command-builder thing,
we can just reuse the nsImageRenderer code.
Differential Revision: https://phabricator.services.mozilla.com/D100774
This is no longer necessary as attach is no longer entering in a nested event loop.
And so we can have attach to complete and return its value as any other request.
Differential Revision: https://phabricator.services.mozilla.com/D100045
We always used to pause when "attaching" the thread actor.
We ought to call ThreadActor's attach method first before using it.
And this method do various things:
* Initialize the Debugger API, enable it, register various listeners, so that breakpoint can work,
* Pause the current thread by starting a nested event loop
So that we also ought to resume the thread, by calling ThreadActor's resume right after attach.
Otherwise the page would be paused as soon as we open the DevTools.
Which sounds like something we might have wanted a very long time ago.
But sounds like pure legacy behavior from today's perspective.
Differential Revision: https://phabricator.services.mozilla.com/D99919
At the moment, the `getParent` method was using the connection `poolFor` method
to retrieve the pool that was managing it. This is quite costly as `poolFor`
loops through all the pools of the connection.
This patch adds a `parentPool` property to the Pool that is set in `manage` and
reset in `unmanage`, and used in the `getParent` method.
This speeds up getParent as well as the methods that call it (`manage` when the
actor was already managed, and `destroy`).
Differential Revision: https://phabricator.services.mozilla.com/D100981
The test creates a lot of nested pools and then stresses a few methods:
- manage
- manage, but with Pools that were already managed by another Pool
- unmanage
- destroy (through the connection disconnection)
Differential Revision: https://phabricator.services.mozilla.com/D100905
This patch displays an error icon matching the number
of errors handled in the console.
An error can be:
- a nsIScriptError that is not a warning
- a console.error call
- a console.assert call
- a 4xx or 5xx network call
The counter is handled via the resourceWatcher of the toolbox,
where we listen for the different resources we need.
Clearing the console from the UI or via console.clear resets
the error count.
Clicking on the icon opens the split console if it wasn't already.
Navigating clears the error count, except if the persist log
option is enabled in the console.
A test is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D100668
DONTBUILD because this is a comment-only change and hence doesn't affect
behavior at all.
I ran across this typo in nsPageFrame.cpp, and figured I might as well grep for
it and fix it more comprehensively. And while I'm at it, I also fixed some
neighboring instances of a duplicated word around a linebreak, in
nsXMLContentSerializer.h.
Differential Revision: https://phabricator.services.mozilla.com/D100852
This patch adds "CPU Utilization" ("cpu" for short) as a new feature that will control the upcoming still-experimental CPU measurements.
Differential Revision: https://phabricator.services.mozilla.com/D99054
Depends on D99610
This patch uses the thunk approach introduced in [Bug 1623906](https://bugzilla.mozilla.org/show_bug.cgi?id=1623906) to replace the `GridInspector.onShowGridOutlineHighlight()` method which is prop-drilled through React components. `onShowGridOutlineHighlight()` is just an alias for `HighlightersOverlay.showGridHighlighter()` without any special handling, so we drop the indirection altogether.
The method is replaced by a new thunk, `showGridHighlighter()` introduced in a new file `client/inspector/grids/actions/grid-highlighter.js`. This thunk is dispatched with options to show a grid highlighter with outlines for the given cell / area, or just the default grid highlighter when no options are given.
The corresponding tests are updated to use the generic events emitted by `HighlightersOverlay` introduced with [Bug 1646028](https://bugzilla.mozilla.org/show_bug.cgi?id=1646028) and the test helpers added in D85858.
Differential Revision: https://phabricator.services.mozilla.com/D99674
Depends on D99609
This patch consolidates logging telemetry in response to the highlighter show/hide lifecycle using the approach introduced for Flexbox highlighter in D96730
`_afterShowHighlighterTypeForNode()` and `_beforeHighlighterTypeForNode()` are generic methods to call in the lifecycle of the highlighter. We use them to run non-critical operations related to showing/hiding highlighters, like logging telemetry. The operations are grouped within by highlighter type.
Differential Revision: https://phabricator.services.mozilla.com/D99610
Depends on D99606
This patch refactors the logic to show/hide CSS Grid highlighters.
It doesn't use the generic highlighter methods introduced with [Bug 1646028](https://bugzilla.mozilla.org/show_bug.cgi?id=1646028) for other highlighters because the special cases for CSS Grid added too much complexity. I decided to keep a parallel implementation which does reuse some of the generic helpers (see other patches in this series).
CSS Grid highlighters are special for a few reasons:
- multiple instances can be visible at the same time (default 3) vs single instance for all other highlighter types; the limit is arbitrary but used as a rudimentary way to guard against performance degradation because each highlighter instantiates a [large canvas](https://searchfox.org/mozilla-central/rev/95cf843de977805a3951f9137f5ff1930599d94e/devtools/server/actors/highlighters/utils/canvas.js#25-43) that hogs the GPU. A smart mitigation was investigated once, but never followed-through [Bug 1232491](https://bugzilla.mozilla.org/show_bug.cgi?id=1232491)
- it is possible to highlight nodes which are not selected in the Inspector
- there is a parent-child relationship between grid and subgrid highlighters (see detailed explanation added in JSDoc for `HighlightersOverlay.showGridHighlighter()`); when one is shown, it influences whether and how the other is shown
- there can be multiple subgrids with the same grid parent
NOTE: Unless otherwise stated inline, please treat the following methods as completely rewritten:
- showGridHighlighter()
- hideGridHighlighter()
- showParentGridHighlighter()
- hideParentGridHighlighter()
In summary, the changes in this patch are:
- refactored `showGridHighlighter()`, `hideGridHighlighter()`, `showParentGridHighlighter()` and `hideParentGridHighlighter()` to use the data from `gridHighlighters` map;
- modified `_getHighlighterTypeForNode()` to return multiple instances for Grid highlighters;
- destroy, not just hide, grid highlighter instances when unused.
Further clean-up and integration with existing generic helpers follows in the next patches in this series.
Differential Revision: https://phabricator.services.mozilla.com/D99591
This patch removes the old grid highlighter management logic. Some of it is gradually replaced by commits later in this series.
The diff with changes made in D99591 turned out very hairy and difficult to follow. To ease review, I completely removed some methods here and reintroduced them in D99591.
Unless otherwise stated, the contents of `showGridHighlighter()`, `hideGridHighlighter()`, `showParentGridHighlighter()` and `hideParentGridHighlighter()` may be considered completely rewritten.
If it helps, you may view the patches side-by-side to observe the difference (the diff view [looked very confusing](https://phabricator.services.mozilla.com/D99591?vs=on&id=378317#toc)).
In summary, the changes in this patch are:
- removed the separate parent grid highlighters map (`parentGridHighlighters`) and subgrid-to-parent mapping (`subgridToParentMap`); this information will be contained in the values of the `gridHighlighters` map which holds all instances of active grid highlighters (added in D99591)
- removed the cache pool for unused highlighters (`extraGridHighlighterPool`); with multi-process separation, this became unnecessarily complex
- removed `_getGridHighlighter()`; replaced with generic highlighter getter in D99591
- removed `destroyGridHighlighters()` reliant on the obsolete maps; replaced with consolidated highlighter destroy approach in D99591
Differential Revision: https://phabricator.services.mozilla.com/D99606
When the user edits a stylesheet in the StyleEditor, an `_isUpdating` flag is toggled,
and a request is sent to the server to actually apply those changes to the stylesheet.
It then causes a style-applied event to be emitted (or the stylesheet resource
to be updated, if watcher support is enabled for stylesheet).
In the end, this triggers the onStyleApplied function in the StyleEditor, where
we check if the `_isUpdating` flag is true (to know if the event was caused
through editing in style editor), and if not, replace the stylesheet content.
Unfortunately there's a race condition when the user is typing (and sending
multiple requests to the server), as the state of the _isUpdating flag could
be wrong if a new request is sent before the first one is handled.
This is probably highlighted with the throttling we're doing in the Resource API.
To fix this issue, we add a new `cause` parameter to the StyleSheets.update method,
which we set to `styleeditor` when calling update within the StyleEditor.
This `cause` parameter is then sent back by the server to the client (via the
style-applied event, or the resource update if we have Watcher support for stylesheets).
This `cause` can be checked by the StyleEditor client, and replace the check
on `_isUpdating`.
However, we need to keep the `_isUpdating` property to handle backward compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D99862
Bogdan Tara
Hubert Boma Manilla
Jon Bauman
Paul Zuehlcke
Nicolas Chevobbe
Emilio Cobos Álvarez
Daisuke Akatsuka
Alexandre Poirot
Kartik Gautam
Gabriel Luong
Abhishek Sharma
Mihai Alexandru Michis
pedrofonsecadev
Rahul Yedida
Daniel Holbert
Markus Stange
Mark Banner
Gerald Squelart
Sebastian Hengst
Julian Descottes
Kaique da Silva
bfmags
Cosmin Sabou
Sonia Singla
Razvan Caliman