This fixes src loads to be consistent with srcset/picture loads, modulo
the special synchronous case in the spec
(https://html.spec.whatwg.org/#update-the-image-data step 7), which
requires src loads to be sync if the image is available.
We now avoid triggering the load from the parser consistently for src /
srcset / picture, and unify the codepath with BindToTree. That should
avoid some useless task allocations.
Only the sync load code-path needs a script runner (mostly to deal with
anonymous content like the video poster <img> and such, but it also
helps not trigger sync loads at unexpected times like on adoption).
About the HTMLImageElement::Complete() getter change, we need to also
return false if there's an existing load task. That is the proposal in
https://github.com/whatwg/html/issues/4884, and prevents some failures
in the-img-element/{update-src-complete,img.complete}.html WPTs. It
technically changes our behavior on .srcset changes, but it makes it
consistent with .src changes and other browsers, so seems fine.
There are a couple regressions in CSP tests and the networkEvent stubs,
but these are really a pre-existing issue. What happens is that, since
the loads are now async, CSP can't figure out the script that triggered
the load anymore. I need to look if there's an easy way to propagate
that information in the image load tasks, but this is trivially
reproducible by changing these tests to use srcset rather than src.
The rest of the test changes are as expected: either new passes, or
expected test changes from this.
Differential Revision: https://phabricator.services.mozilla.com/D215519
This should allow the number of hidden messages to be notified to
screen reader users.
We update the Console FilterBar behavior to always show the "X hidden" message
when the input is focused, so screen reader can also pick up when no messages
are hidden.
Differential Revision: https://phabricator.services.mozilla.com/D213181
The enhancer was brittle as nothing was waiting for its completion.
We should rather do such work from the action layer. At least this can delay the action completion,
which the test header (setFilterState) already wait for.
Differential Revision: https://phabricator.services.mozilla.com/D205602
The enhancer was brittle as nothing was waiting for its completion.
We should rather do such work from the action layer. At least this can delay the action completion,
which the test header (setFilterState) already wait for.
Differential Revision: https://phabricator.services.mozilla.com/D205602
The enhancer was brittle as nothing was waiting for its completion.
We should rather do such work from the action layer. At least this can delay the action completion,
which the test header (setFilterState) already wait for.
Differential Revision: https://phabricator.services.mozilla.com/D205602
For now we were releasing object actors one by one.
This would force to send an individual RDP request for each of them.
The console often release all objects actors related to older console message
going over the maximum limit of displayed console messages (10k).
This can easily grow in a large number of actors to be released,
either if console message are receiving many arguments and/or
if many console are logged.
We have to have one request per target as the actors could only be reached
within same-thread actor.
In order to prepare for ObjectFront removal, introduce a target-scoped "Objects" actor
which is a singleton per Target. It will receive the new "release in bulk objects actors"
method. Later, it will start implementing all the existing methods of the Object Actor
in order to migrate away from having to instantiate one Object Front (notice the singular on "Object"),
per inspected JS Object.
On the fronted side a new Object Command is introduced in order to abstract away the RDP/Fronts work.
Differential Revision: https://phabricator.services.mozilla.com/D198784
For now we were releasing object actors one by one.
This would force to send an individual RDP request for each of them.
The console often release all objects actors related to older console message
going over the maximum limit of displayed console messages (10k).
This can easily grow in a large number of actors to be released,
either if console message are receiving many arguments and/or
if many console are logged.
We have to have one request per target as the actors could only be reached
within same-thread actor.
In order to prepare for ObjectFront removal, introduce a target-scoped "Objects" actor
which is a singleton per Target. It will receive the new "release in bulk objects actors"
method. Later, it will start implementing all the existing methods of the Object Actor
in order to migrate away from having to instantiate one Object Front (notice the singular on "Object"),
per inspected JS Object.
On the fronted side a new Object Command is introduced in order to abstract away the RDP/Fronts work.
Differential Revision: https://phabricator.services.mozilla.com/D198784
Instead of rendering the cropped URL, we split the URL in 3 parts, so the full
URL text will be in the DOM, but we visually hide the middle part and replace
it with an ellipsis.
This way copying the message will still put the full URL in the clipboard.
A test case is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D165805
This makes the console behave like the other React panels.
We can also get rid of the specific bits for mocha in devtools-node-test-runner.js
Differential Revision: https://phabricator.services.mozilla.com/D167233
Note that there is still one leftover usage of sessionId related to performance markers,
which isn't related to telemetry... but a way to distinguish toolbox instances.
Differential Revision: https://phabricator.services.mozilla.com/D165936
This was no longer implemented/shown in the fission browser toolbox.
Now that we removed the non-fission toolbox, we can remove this feature.
Instead, content process messages are shown/hidden depending on browser toolbox's scope.
"everything" will show them. "parent-process" won't.
Differential Revision: https://phabricator.services.mozilla.com/D165026
All calls to `writeStubsToFile` were updated, but not the function signature itself,
which we do in this patch.
We also take this as an opportunity to fix the require calls in the stub file template.
Differential Revision: https://phabricator.services.mozilla.com/D163489
This will help transition to ES Modules as we won't be able to expose a magic "chrome" ESM.
Also, most of these symbols are exposed as global already.
All but:
* `components` which is `Components`,
* `CC` which is `Components.Constructor`,
* `Cm` which is `Components.manager`.
$ sed -ie "/require(.chrome.)/d" $(git grep -l 'require("chrome")' devtools/)
+ manual edits for all three exceptions
Differential Revision: https://phabricator.services.mozilla.com/D156936
This will help transition to ES Modules as this symbol is exposed to them.
$ sed -ie "/require(.ChromeUtils.)/d" $(git grep -l 'require("ChromeUtils")' devtools/)
$ sed -ie "/loader.lazyRequireGetter(this, .ChromeUtils./d" $(git grep -l 'loader.lazyRequireGetter(this, "ChromeUtils"' devtools/)
+ the edition of builtin-modules.js + eslintrc.js + manual eslint fixes
Differential Revision: https://phabricator.services.mozilla.com/D156402
This will help transition to ES Modules as this symbol is exposed to them.
$ sed -ie "/require(.Services.)/d" $(git grep -l 'require("Services")' devtools/)
$ sed -ie "/loader.lazyRequireGetter(this, .Services./d" $(git grep -l 'loader.lazyRequireGetter(this, "Services"' devtools/)
+ the edition of builtin-modules.js + eslintrc.js
+ manual eslint fixes
+ removal of devtools-services in the debugger, except for jest tests
Differential Revision: https://phabricator.services.mozilla.com/D156401
It looks like there was some (hardware?) changes on TRY
which caused the test to run in Coordinated Universal Time
timezone, when one test expect it to be CEST.
We force the timezone in the test command so it will
always be CEST.
Differential Revision: https://phabricator.services.mozilla.com/D155818
This was only _not_ rendering when `terminalEagerResult` was `null`, but with
Bug 1776376, we're getting `undefined` results in some case, which was crashing
the component.
While this should be fixed at an upper level, this patch makes the component a bit
more robust so we don't crash the whole console client.
A node test is added for basic rendering with various result values, and proper
mochitest will be added in follow-up patches in this queue.
Differential Revision: https://phabricator.services.mozilla.com/D152161
This introduces functionality to support disabling weconsole messages.
Also introduces code to disable all network messages, which would be
used by the netmonitor.
You'll probably need the fullstack of patches to test easily
Will add mochitest in a followup
Differential Revision: https://phabricator.services.mozilla.com/D149753
`WebConsoleConnectionProxy` is now only used for:
- listening to `lastPrivateContextExited`, which can be done from the top-level
console front instead
- setting `NetworkMonitor.saveRequestAndResponseBodies` for toolbox we don't have
network resource support for, which would be better done in `startWatchingNetworkResources`.
This means we don't need to keep a Map of additional proxies.
The only impact is on `clearMessagesCache`, where we now fetch all fronts with
`getAllFronts` instead of looping through the Map of additional proxies.
This change highlighted some race condition in tests, as it's now slightly slower.
So we add a new `clearMessagesCacheAsync` function, which is doing the same thing
as `clearMessagesCache`, except it's not `oneway`, so we can know when the cache
was indeed cleared, and we emit an event to indicate when the cache was cleared.
We can't simply remove `oneway` from `clearMessagesCache` as it causes backward
compatibility issues we can't avoid.
This also highlighted an issue with the cache not being cleared on `console.clear`
when it is batched, so we fix this (a test was failing without it).
The next patch in the queue will completely remove `WebConsoleConnectionProxy`.
Differential Revision: https://phabricator.services.mozilla.com/D150085
In the console we might receive messages that need to be inserted at a specific
position in the output to respect the chronological order.
This is very visible when evaluating an expression in the console while we are
fetching cached messages, or when the expression is logging lots of messages, since
the evaluation result doesn't go through the ResourceCommand itself.
Since we were relying on the order of insertion in `mutableMessagesById` for the
order of messages in the output, we had no choice but clone the Map to insert
the new message at the specific position.
With lots of messages, this can be utterly slow, and is something people are experiencing.
To fix this, we're adding a new state property, `mutableMessagesOrder`, which holds
message ids in the chronological order. It's then used to compute `visibleMessages`.
As we don't have to clone the Map anymore, it makes reordering as fast as looking
for an index in the array and splicing it (which is fast).
We also take this opportunity to switch away from our `findIndex` usage; most often
than not, the messages will be reinserted at the end of the array, so we can loop
through it backward to find the index faster.
We still keep `mutableMessagesById` as a Map so lookup are fast, and we don't have
to deal with impacts we'd have if we'd switch to an object.
The existing node test helper to get a message at a specific index are migrated
to make use of `mutableMessagesOrder`, and a few test cases and assertions are
added to check that the new property is handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D148658
Highlights
- Network monitoring is turned off by default in browser console/ browser toolbox console on initial load.
- A new "Enable Network Monitoring" setting is added to enable users toggle on an off as they desire.
- The user setting is persisted across toolbox reopens.
Differential Revision: https://phabricator.services.mozilla.com/D145234
Highlights
- Network monitoring is turned off by default in browser console/ browser toolbox console on initial load.
- A new "Enable Network Monitoring" setting is added to enable users toggle on an off as they desire.
- The user setting is persisted across toolbox reopens.
Differential Revision: https://phabricator.services.mozilla.com/D145234
Henrik Skupin