The patch for Bug 724505 changed the return of `prettifyCSS()` from a string to an object and the reference in the StyleRuleActor.getRuleText() was not updated. This patch fixes this and introduces a test.
Differential Revision: https://phabricator.services.mozilla.com/D38673
--HG--
extra : moz-landing-system : lando
We used to have another provider which would load module via file:// URI,
directly from the disk. But the progress on artifact builds and ./mach build faster
made this obsolete and has been removed a long time ago.
We still have a lot of abstraction to support this non-existent feature.
Differential Revision: https://phabricator.services.mozilla.com/D38284
--HG--
extra : moz-landing-system : lando
My preference was to annotate most of the failing tests with `fail-if` so that
if they start passing, the `fail-if` needs to be removed and they need to keep
passing. That doesn't work for tests that timeout, or which trigger failures
from their cleanup functions, however, so those tests need skip-if. And tests
with fail in their cleanup functions likely leave the browser in an
inconsistent state for subsequent tests, anyway, so really should be skipped
regardless.
There are some remaining tests which still fail because of crashes. I chose
not to skip them here, but to fix the crashes in separate bugs instead.
Differential Revision: https://phabricator.services.mozilla.com/D38247
--HG--
extra : rebase_source : 39ba8fec2e882cfe577c5f2b58ab7e4b461f1178
Given that `CssProperties.isValidOnClient()` does only a client-side check for support of a CSS declaration, we can leverage the built-in `CSS.supports()` method and remove some of the inter-dependencies between the `CssProperties` object from the `CssPropertiesFront` and its consumers, `OutputParser` and `FilterWidget`.
Differential Revision: https://phabricator.services.mozilla.com/D37751
--HG--
extra : moz-landing-system : lando
ChromeUtils.import still support a second argument as it used to do
when it was Components.utils.import. But this is deprecated and we should
instead always use the returned value.
Differential Revision: https://phabricator.services.mozilla.com/D37708
--HG--
extra : moz-landing-system : lando
PowerOfTwo makes for a cleaner and more expressive interface, showing that the
profiler will use a power-of-2 storage size.
Using PowerOfTwoMask in ProfilerBuffer also makes it more obvious that we want
cheap modulo operations.
And we don't need to keep the original capacity, as it's only used once and can
easily be recomputed from the mask.
Differential Revision: https://phabricator.services.mozilla.com/D36027
--HG--
extra : moz-landing-system : lando
We take this as an opportunity to clean-up the function that
waits for the evaluation result.
This change was causing an issue in main.js `_queueResponse`.
Previously, since `evaluateJsAsync` wasn't returning anything,
`_queueResponse` wouldn't be called (See https://searchfox.org/mozilla-central/rev/928742d3ea30e0eb4a8622d260041564d81a8468/devtools/server/main.js#1305-1308).
But now `ret` isn't falsy (the async function always return a
Promise), which means we ended up trying to send a response.
To fix this, we simply check if the response isn't falsy, or we
bail out.
Differential Revision: https://phabricator.services.mozilla.com/D35985
--HG--
extra : moz-landing-system : lando
This was a difficult situation. We are not waiting for a server response when setting or
removing breakpoints. The result is that the server has not completed those actions by the time the
test closed, leaving setBreakpoint or removeBreakpoint requests hanging, causing a number of tests
to fail. In order to get around this, I made the panel action "SET_BREAKPOINT" and
"REMOVE_BREAKPOINT" aware of the server response. This involved rewriting the helper methods
`clientSetBreakpoint` and `clientRemoveBreakpoint` so that they no longer relied on the dispatch.
It was not possible to use the dispatches to wait, as they had no event exposed to the tests,
especially in cases when we triggered these requests via button presses.
Differential Revision: https://phabricator.services.mozilla.com/D32710
--HG--
extra : moz-landing-system : lando
The webConsoleFront and the threadClient front both used to depend on the debugger-client
to destroy them via registered clients. This is no longer the case, and this code can be deleted
Differential Revision: https://phabricator.services.mozilla.com/D32699
--HG--
extra : moz-landing-system : lando
In order for a front to be available to getFront on a given target, it must be first --
registered on the target scope, and second -- set on the target's targetForm. This makes that update
for both browsing context and worker targets. This works as part of a work around until we can get
the server into better shape.
Differential Revision: https://phabricator.services.mozilla.com/D32698
--HG--
extra : moz-landing-system : lando
The resume case is much more complex than the other events, because we do an
unsafeSynchronize to send an unsolicited pause. In the old system, the resume response would have
been ignored, but that is no longer the case. With the new system, we do not want to send a response
to a resume action if it did not come from the UI. This also update the debugger panel code to
accept a resume.
Differential Revision: https://phabricator.services.mozilla.com/D32697
--HG--
extra : moz-landing-system : lando
This is part one of removing threadClient specifics out of the debuggerClient. We were
managing messages from the thread client in a special way -- this was the "Unsolicited Pauses"
object that we had before. This patch updates the threadClient to use Front style events. This
required updating the spec for the threadClient, and several of the methods. What has not been fully
migrated here is the "resumed" event, as this is much more complex. This is taken care of in the
next patch.
Differential Revision: https://phabricator.services.mozilla.com/D32695
--HG--
extra : moz-landing-system : lando
This is the first part of the threadClient refactor. It only moves the methods to the new
front. and does some basic fixes.
Differential Revision: https://phabricator.services.mozilla.com/D32692
--HG--
extra : moz-landing-system : lando
We take this as an opportunity to add tests for `align-self` as well.
This requires the test to change a bit so we can create more than one
element in order to test the inactive property helper on grid/flex item
(i.e. with a parent flex/grid container).
This is done by providing a `createTestElement` function in the test case,
that creates whatever nodes it need and append it in the rootNode parameter.
The function then returns the element that needs to be tested with isPropertyUsed.
Differential Revision: https://phabricator.services.mozilla.com/D34714
--HG--
extra : moz-landing-system : lando
This was a difficult situation. We are not waiting for a server response when setting or
removing breakpoints. The result is that the server has not completed those actions by the time the
test closed, leaving setBreakpoint or removeBreakpoint requests hanging, causing a number of tests
to fail. In order to get around this, I made the panel action "SET_BREAKPOINT" and
"REMOVE_BREAKPOINT" aware of the server response. This involved rewriting the helper methods
`clientSetBreakpoint` and `clientRemoveBreakpoint` so that they no longer relied on the dispatch.
It was not possible to use the dispatches to wait, as they had no event exposed to the tests,
especially in cases when we triggered these requests via button presses.
Differential Revision: https://phabricator.services.mozilla.com/D32710
--HG--
extra : moz-landing-system : lando
The webConsoleFront and the threadClient front both used to depend on the debugger-client
to destroy them via registered clients. This is no longer the case, and this code can be deleted
Differential Revision: https://phabricator.services.mozilla.com/D32699
--HG--
extra : moz-landing-system : lando
In order for a front to be available to getFront on a given target, it must be first --
registered on the target scope, and second -- set on the target's targetForm. This makes that update
for both browsing context and worker targets. This works as part of a work around until we can get
the server into better shape.
Differential Revision: https://phabricator.services.mozilla.com/D32698
--HG--
extra : moz-landing-system : lando
The resume case is much more complex than the other events, because we do an
unsafeSynchronize to send an unsolicited pause. In the old system, the resume response would have
been ignored, but that is no longer the case. With the new system, we do not want to send a response
to a resume action if it did not come from the UI. This also update the debugger panel code to
accept a resume.
Differential Revision: https://phabricator.services.mozilla.com/D32697
--HG--
extra : moz-landing-system : lando
This is part one of removing threadClient specifics out of the debuggerClient. We were
managing messages from the thread client in a special way -- this was the "Unsolicited Pauses"
object that we had before. This patch updates the threadClient to use Front style events. This
required updating the spec for the threadClient, and several of the methods. What has not been fully
migrated here is the "resumed" event, as this is much more complex. This is taken care of in the
next patch.
Differential Revision: https://phabricator.services.mozilla.com/D32695
--HG--
extra : moz-landing-system : lando
This is the first part of the threadClient refactor. It only moves the methods to the new
front. and does some basic fixes.
Differential Revision: https://phabricator.services.mozilla.com/D32692
--HG--
extra : moz-landing-system : lando
The inactive CSS feature is only enabled in Nightly at
the moment, which is what's causing the test to fail
on beta simulation.
Forcing the pref to true in the test should fix the issue.
Differential Revision: https://phabricator.services.mozilla.com/D34847
--HG--
extra : moz-landing-system : lando
There was an issue where this test was timing out, and due to the way it was written it was
very hard to identify where -- there were many nested promises. I rewrote the test in order to
identify the time out.
Differential Revision: https://phabricator.services.mozilla.com/D32714
--HG--
extra : moz-landing-system : lando