The `clear` property currently only applies to block-Level elements, not to floats, regions, or pages, because the related CSS Page Floats Module (https://www.w3.org/TR/css-page-floats-3/) is not implemented yet.
For the same reason, we don't check `float-offset` and `float-defer` at the moment.
Differential Revision: https://phabricator.services.mozilla.com/D215299
This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
As per the comments it isn't supported with cache-the-world on, it's
barely documented if at all, and a test for it seems to be failing
without me being able to reproduce it at least (tried on both windows
and Linux).
I don't think it's worth digging too much more into it. My guess is a
reentrant / differently timed a11y event caused by my scheduling
changes, or so, which would override sEventTargetNode or the other
static bool.
The test has ~always failed on macOS too...
Differential Revision: https://phabricator.services.mozilla.com/D210872
This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
This is done to avoid a performance issue with deeply nested rules,
where computing the desugared selector can be super expensive.
This should help overall since we're doing a bit less work, as well
as returning smaller data.
Differential Revision: https://phabricator.services.mozilla.com/D207727
This revision updates newly-failing tests after implementing the ancestor
requirements for certain child roles. Generally, this revision adds ancestors
where appropriate, because tests largely are not testing this particular
behavior.
Differential Revision: https://phabricator.services.mozilla.com/D205880
`InspectorUtils.getRuleBodyTextOffset` was returning bytes position, and we
were using them directly in Javascript `substring`, which causes problem
with non-ascii chars.
Instead of returning offsets to compute the rule string, we directly return
the string from InspectorUtils which is easier to work with.
Differential Revision: https://phabricator.services.mozilla.com/D204523
This revision updates newly-failing tests after implementing the ancestor
requirements for certain child roles. Generally, this revision adds ancestors
where appropriate, because tests largely are not testing this particular
behavior.
Differential Revision: https://phabricator.services.mozilla.com/D205880
This code was only used for workers targets, which weren't passing breakpoints
from the server side via "sessionData" concept.
Instead, we were still relying on the frontend to pass them and only after that
manually requesting the thread to resume its execution.
Now, there is still a notion of "attach" around the thread actor.
While all the targets are immediately instantiating their related thread actor,
the thread actor isn't active by default.
It becomes active as soon as:
* SOURCE or THREAD_STATE resource is watched
* breakpoints are set via session data (breakpoint list actor)
* thread configuration are set via session data (thread configuration actor)
I had to do one of these things in order to keep test from working.
In the production code, we do most of these things by default on the toolbox startup.
We could revise this behavior by:
* always attaching the thread actor, but it may start pausing unexpectedly in some tests.
* decouple sources from breakpoints within the thread actor, so that watching for sources doesn't necessarily "attach" the thread actor and activate breakpoints/debugger statements.
* have a new thread configuration to explicitly enable the thread actor pausing features.
I'm often using thread configuration to enable pausing in tests.
This required to improve xpcshell test helpers to be able to use Watcher/Commands.
About browser_target_command_bfcache.js, the DevTools code is now so quick that the
back/forward requests at done too quickly one after the other and fail actually moving to
the other document.
Differential Revision: https://phabricator.services.mozilla.com/D166321
We were only processing the first one being registered.
Luckily we weren't testing session data enough in xpcshell to have trouble because of this.
(this changeset fixes test failure when applying the next one)
Differential Revision: https://phabricator.services.mozilla.com/D203101
Since we're at the end of the cycle, let's fix the regression
by reverting getRuleText to use the JS lexer again.
A test case is added to prevent future regression when we'll
try to move this to an InspectorUtils method again.
Differential Revision: https://phabricator.services.mozilla.com/D204621
This code was only used for workers targets, which weren't passing breakpoints
from the server side via "sessionData" concept.
Instead, we were still relying on the frontend to pass them and only after that
manually requesting the thread to resume its execution.
Now, there is still a notion of "attach" around the thread actor.
While all the targets are immediately instantiating their related thread actor,
the thread actor isn't active by default.
It becomes active as soon as:
* SOURCE or THREAD_STATE resource is watched
* breakpoints are set via session data (breakpoint list actor)
* thread configuration are set via session data (thread configuration actor)
I had to do one of these things in order to keep test from working.
In the production code, we do most of these things by default on the toolbox startup.
We could revise this behavior by:
* always attaching the thread actor, but it may start pausing unexpectedly in some tests.
* decouple sources from breakpoints within the thread actor, so that watching for sources doesn't necessarily "attach" the thread actor and activate breakpoints/debugger statements.
* have a new thread configuration to explicitly enable the thread actor pausing features.
I'm often using thread configuration to enable pausing in tests.
This required to improve xpcshell test helpers to be able to use Watcher/Commands.
About browser_target_command_bfcache.js, the DevTools code is now so quick that the
back/forward requests at done too quickly one after the other and fail actually moving to
the other document.
Differential Revision: https://phabricator.services.mozilla.com/D166321
We were only processing the first one being registered.
Luckily we weren't testing session data enough in xpcshell to have trouble because of this.
(this changeset fixes test failure when applying the next one)
Differential Revision: https://phabricator.services.mozilla.com/D203101
By protocol.js conventions, most target scopes actors have a `targetActor` attribute set to their parent,
i.e. the related target actor. Thread Actor was old enough to not follow this pattern.
Also remove the second constructor argument and `global` attribute as it was unused.
Differential Revision: https://phabricator.services.mozilla.com/D201696
This revision adds a Gecko GRID role, matching the ARIA 'grid' role, and
implements its platform mappings. It then remaps the ARIA 'grid' role to the
Gecko GRID role. Finally, this revision removes the expected-fail for the
relevant formerly-failing web platform test and updates existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D202040
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
Andrea Marchesini