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
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
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
Since capture.js was only loaded by server files and
save.js by client files, there wasn't any reason to
have them in devtools/shared.
The files are moved and the references are updated.
Differential Revision: https://phabricator.services.mozilla.com/D101142
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
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
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
When pausing in a content process script in the Browser Toolbox (e.g. somewhere
in devtools/server), we tried to display the PausedDebuggerOverlay, which was
causing an error to be displayed in the CanvasFrameAnonymousContentHelper, as
we didn't have access to a documentElement property it needed.
This happens because the _canShowOverlay method in the thread actor was only
checking for the presence of a window property on the target actor.
Unfortunately, the ContentProcessTargetActor does expose a window getter, which
is a Sandbox, and thus doesn't have a document.
This patch modifies the _canShowOverlay function to check that we do have access
to a documentElement.
Differential Revision: https://phabricator.services.mozilla.com/D99899
