The documents don't really matter here, they are empty. But the URL shows up in the resources. I guess alternatively we could also have a single test-empty.html for such use cases.
Differential Revision: https://phabricator.services.mozilla.com/D266962
The existing setting was added to control grouping similar warning messages.
Due to the wording of the setting, users were also thinking it could control
repeated messages (the small badge/bubble we put next to messages when successibe
messages have the same text).
This patch renames the warning group pref into something that can drive both of
these, and we make the repeat mechanism check the value of the pref befor repeating.
Note that for repeated message, unlike warning groups, this doesn't "ungroup"
the messages, but that should be fine like this.
A node test case is added, as well as a mochitest (event though the test was already
checking repeated messages in a specific context, it's still nice to have
some basic actual coverage)
Differential Revision: https://phabricator.services.mozilla.com/D257841
Lets start triggering updates at certain keypoint in the cycle instead
batching into one update at the end.
This should depend on mechanisim for throttling resources so as not to spam the
frontend with lots of updates
Differential Revision: https://phabricator.services.mozilla.com/D247424
This consolidates the jest environment definition, and the xpcshell globals into the devtools/.eslintrc.mjs file, for easier configurations.
It also changes the restart of the configurations to work with flat config.
Differential Revision: https://phabricator.services.mozilla.com/D249948
We still need to keep the page error stubs because they're used in other tests,
but we remove all the ones that were solely used in pageError.js
Differential Revision: https://phabricator.services.mozilla.com/D230517
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
Alexandra Borovova