Moved network monitor actor files:
network-monitor.js
network-event.js
into devtools/server/actors/network-monitor directory.
And updated moz.build files presented in related directories.
Differential Revision: https://phabricator.services.mozilla.com/D38219
--HG--
rename : devtools/server/actors/network-event.js => devtools/server/actors/network-monitor/network-event.js
rename : devtools/server/actors/network-monitor.js => devtools/server/actors/network-monitor/network-monitor.js
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
A test is added to ensure this is fixed properly.
We also fix the Array previewer to properly return
undefined for unknown array properties, rather than null.
Differential Revision: https://phabricator.services.mozilla.com/D38467
--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
Moved network monitor actor files:
network-monitor.js
network-event.js
into devtools/server/actors/network-monitor directory.
And updated moz.build files presented in related directories.
Differential Revision: https://phabricator.services.mozilla.com/D38219
--HG--
rename : devtools/server/actors/network-event.js => devtools/server/actors/network-monitor/network-event.js
rename : devtools/server/actors/network-monitor.js => devtools/server/actors/network-monitor/network-monitor.js
extra : moz-landing-system : lando
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
Storage principal is the principal used for the storage area of a document,
as well as when trying to communicate to other same-origin document instances.
Right now the default is for the storage principal to be equal to the node
principal for all documents, but in the dynamic FPI feature (bug 1549587)
the storage principal for third-party documents will have a member of its
origin attributes set to the eTLD+1 of the domain of the top-level document
in order to 'partition' third-party data across top-level documents from
different sites.
This patch moves the devtools storage actor to use the storage principal
so that when dynamic FPI is enabled, devtools uses the correct principal.
Differential Revision: https://phabricator.services.mozilla.com/D37664
--HG--
extra : moz-landing-system : lando
The console fails to connect to the server because
the getCachedMessages function throws on GMail.
This is because we try to access a property on a
cross-origin object, window.windowUtils, in
getInnerWindowId.
Wrapping the access to the property fixes the issue.
A test is added to make sure we don't regress.
// TODO: The test isn't failing without the fix,
so it should be re-written.
Differential Revision: https://phabricator.services.mozilla.com/D37069
--HG--
extra : moz-landing-system : lando
This implements the context menu items for the DOM mutation breakpoint.
In addition, there were some server changes to:
- Update the mutationBreakpoints form for the NodeActor
- Expose the mutationBreakpoints form
- Moved the setMutationBreakpoints method from the Node spec to Walker spec
since the Node spec only consisted of getter methods. It made more sense
that the setter went into the Walker spec to be more consistent with how
the Walker and Node spec have been arranged.
Unit tests will be followed up in Part 2 immediately.
Differential Revision: https://phabricator.services.mozilla.com/D36074
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
Showing moz-extension URLs in the debugger is not helpful -- we should display the name of the extension instead.
Differential Revision: https://phabricator.services.mozilla.com/D34427
--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
We put some objects on the InactivePropertyHelper (node, rule),
but never reset those properties, which was causing leaks in some
inspector tests.
This patch adds a unselect function that clears all the references
added in the select function.
Differential Revision: https://phabricator.services.mozilla.com/D34844
--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
There were a few miscellaneous situations in which the test would fail due to a hanging
request. These tests passed in the past because the old way of using the threadActor did not
identify which requests had been responded to.
Differential Revision: https://phabricator.services.mozilla.com/D32711
--HG--
extra : moz-landing-system : lando
If logpoint throws, set `level` to "error".
Add tests to ensure the correct level is set.
Demo function: https://luxuriant-system.glitch.me/
Add some logpoints. The first two statements are invalid. The third one is valid.
{F1311386}
In console:
{F1311387}
Differential Revision: https://phabricator.services.mozilla.com/D31157
--HG--
extra : moz-landing-system : lando
This should make the test more managable as we add properties
validators in InactivePropertyHelper.
eslint doesn't support dynamic import yet, so we have to ignore
the test file.
Differential Revision: https://phabricator.services.mozilla.com/D34677
--HG--
rename : devtools/server/tests/mochitest/test_inspector-inactive-property-helper.html => devtools/server/tests/mochitest/inactive-property-helper/gap.js
rename : devtools/server/tests/mochitest/test_inspector-inactive-property-helper.html => devtools/server/tests/mochitest/inactive-property-helper/max-min-width-height.js
rename : devtools/server/tests/mochitest/test_inspector-inactive-property-helper.html => devtools/server/tests/mochitest/inactive-property-helper/vertical-align.js
extra : moz-landing-system : lando
Element.nodeName is usually all-caps, and we were testing lower cased version,
which brought erroneous results.
The test wasn't picking those errors because we were creating the element from
a XHTML document, where Element.nodeName keep the casing used for their creation.
The test is modified to deal with an HTML document instead.
After the test was modified, I could see it was failing, and was then able to
do the actual feature fix.
Differential Revision: https://phabricator.services.mozilla.com/D34149
--HG--
rename : devtools/server/tests/browser/browser_inspector-inactive-property-helper.js => devtools/server/tests/mochitest/test_inspector-inactive-property-helper.html
extra : moz-landing-system : lando
Indicate in the infobar highlighter if the element is of kind grid or flex, and if it is a container or an item.
Differential Revision: https://phabricator.services.mozilla.com/D29964
--HG--
extra : moz-landing-system : lando
This is done so the user has a choice what kind of audit to run or what kind of audit type to filter the accessibility tree by
Differential Revision: https://phabricator.services.mozilla.com/D33183
--HG--
extra : moz-landing-system : lando
This introduce a new form of invalid messages. Until now, all the
messages were like "X has no effect on this since it's not Y".
But in this case, the width/height properties applies to all but
a few cases, which means we can't really keep the same shape of
message (or it would be "since it's not A, B, C, D, ...).
So we're switching to a message that prints the display property
of the element ("X has no effect on this element since it has a
display of Y").
In order to do that, we need to pipe the element computed display
into the inactive tooltip.
Differential Revision: https://phabricator.services.mozilla.com/D32805
--HG--
extra : moz-landing-system : lando
support for from-font listed in the CSS spec will be implemented in a later bug
Differential Revision: https://phabricator.services.mozilla.com/D33233
--HG--
extra : moz-landing-system : lando
Depends on D32867
Reference the shared list of pseudo-elements throughout the codebase:
- markup view context menu + test
- Rule editor
- box model highlighter
- node actor
- new Rules view
Differential Revision: https://phabricator.services.mozilla.com/D32868
--HG--
extra : moz-landing-system : lando
- Removes the hardcoded references from `index.xhtml` and `rules.js` and uses a centralized list of pseudo-classes to generate the checkboxes for the supported pseudo-class locks at runtime.
- Streamlines the handling for pseudo-class locks state. Fixes Bug 1536676 as a side-effect.
- Updates tests.
Differential Revision: https://phabricator.services.mozilla.com/D32867
--HG--
extra : moz-landing-system : lando
Since isPropertyUsed takes an HTMLElement and its computed style, we
need to have access to the DOM, and can't use an xpcshell test.
Differential Revision: https://phabricator.services.mozilla.com/D33454
--HG--
extra : moz-landing-system : lando
r=jdescottes
turns out we were incorrectly passing the threadClient to the environmentClient while
instantiating in one of the tests. It worked before because the threadClient exposed the API surface
of the debugger-client.
Differential Revision: https://phabricator.services.mozilla.com/D32685
--HG--
extra : moz-landing-system : lando
Displays blocked requests in the Network monitor request listing, providing a reason for why the request was blocked based on response codes provided b nsILoadInfo.idl
Differential Revision: https://phabricator.services.mozilla.com/D31907
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
Jeremy
Brindusan Cristian
Jason Laster
Oana Pop Rus
Brian Hackett
Alexandre Poirot
Nicolas Chevobbe
tanhengyeow
Kris Maglione
Mihai Alexandru Michis
jaril
Yura Zenevich
Maliha Islam
Coroiu Cristina
Narcis Beleuzu
Ciure Andrei
Gijs Kruitbosch
Razvan Caliman
Dorel Luca
Daniel Varga
Ehsan Akhgari
yulia
Panos Astithas
Jonathan Kingston
Victor Porof
Logan Smyth
shindli
Gabriel Luong
Cosmin Sabou
Julian Descottes
Gerald Squelart
Charlie Marlow
Andreea Pavel
Nicholas Nethercote
Connor Brewster
David Walsh
chujun
arthur.iakab
violet
Thomas
Micah Tigley
Bogdan Tara
Csoregi Natalia
Michael Ratcliffe
Nicolas B. Pierron
Nicolas B. Pierron
Emilio Cobos Álvarez
Andrea Marchesini
Ashley Hauck
Patrick Brosset
Boris Chiou
Jean-Yves Avenard