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
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
- 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
`isInherited` is a callback function that checks if a given CSS property is inherited. It is misleadingly commented as a cache of inherited properties (which perhaps it is on the InspectorUtils implementation, but on the consumer side it is just a function).
The actual call is done by InspectorUtils.isPropertyInherited. There is no need to pass the handler to CssLogic or to CssPropertyInfo since InspectorUtils is available in the same context as the definition of the consumers.
There is no other use case where a custom handler is passed to check for inherited properties in so it is safe to remove this as an argument and just use InspectorUtils.isPropertyInherited where needed. This cleans up the code slightly.
Differential Revision: https://phabricator.services.mozilla.com/D32016
--HG--
extra : moz-landing-system : lando
Finally! the goal of all of this: removing three functions from threadClient that really belong as part of source client. PauseLongString is never used except in tests. ThreadLongString is only ever used by sourceClient. Same goes for the arrayBuffer method. This clears all of that out.
Differential Revision: https://phabricator.services.mozilla.com/D21715
--HG--
extra : moz-landing-system : lando
After toggling off 'Pause on exceptions' in the debugger, exceptions were still being paused on once.
This was because the server's exception-pausing behavior was not toggled off until an exception was paused on. This patch makes it so that the behavior is changed immediately after unchecking the 'Pause on exceptions' checkbox in the debugger.
Differential Revision: https://phabricator.services.mozilla.com/D27453
--HG--
extra : moz-landing-system : lando
BrowserTabList._actorByBrowser still contains opened tab we attached
to when destroying the RootActor. This prevents correctly unregistering
the DOM listener set on browser.xul, leading to permanent leaks.
Differential Revision: https://phabricator.services.mozilla.com/D26110
--HG--
extra : moz-landing-system : lando
After toggling off 'Pause on exceptions' in the debugger, exceptions were still being paused on once.
This was because the server's exception-pausing behavior was not toggled off until an exception was paused on. This patch makes it so that the behavior is changed immediately after unchecking the 'Pause on exceptions' checkbox in the debugger.
Differential Revision: https://phabricator.services.mozilla.com/D27453
--HG--
extra : moz-landing-system : lando
Depends on D27468
As suggested, some additonal tests that should be skipped on this platform.
A first batch of tests were disabled in Bug 1533184
Differential Revision: https://phabricator.services.mozilla.com/D27558
--HG--
extra : moz-landing-system : lando
I changed DelegatedQueryInterface and CallMethod to be non-static
methods rather than taking an explicit |self| parameter.
There is already a method nsXPCWrappedJS::CallMethod() with the same
signature, but it is a shim, so I inlined it into the version in
XPCWrappedJSClass.cpp.
I also fixed up a few comments that mention nsXPCWrappedJSClass.
The new comments starting with "We now need to enter the realm" were
written by Boris, and are a little more explicit so they are easier to
understand.
I renamed DebugDump() to DebugDumpInterfaceInfo() to be more
informative.
Differential Revision: https://phabricator.services.mozilla.com/D26422
--HG--
extra : moz-landing-system : lando
I changed DelegatedQueryInterface and CallMethod to be non-static
methods rather than taking an explicit |self| parameter.
I did a tiny bit of cleanup in the nsIXPConnectJSObjectHolder case of
DelegatedQueryInterface().
There is already a method nsXPCWrappedJS::CallMethod() with the same
signature, but it is a shim, so I inlined it into the version in
XPCWrappedJSClass.cpp.
I also fixed up a few comments that mention nsXPCWrappedJSClass.
The new comments starting with "We now need to enter the realm" were
written by Boris, and are a little more explicit so they are easier to
understand.
I renamed DebugDump() to DebugDumpInterfaceInfo() to be more
informative.
Differential Revision: https://phabricator.services.mozilla.com/D26422
--HG--
extra : moz-landing-system : lando
We add a new `BigInt` grip type that can be consumed by reps.
A few test cases are added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D24669
--HG--
extra : moz-landing-system : lando
There is one spot I am unsure about, and that is the test:
devtools/server/tests/unit/test_threadlifetime-06.js -- should this be kept or do we want to remove
it as well?
Differential Revision: https://phabricator.services.mozilla.com/D21674
--HG--
extra : moz-landing-system : lando
The only fishy bit is the animation stuff. In particular, there are two places
where we just mint the revert behavior:
* When serializing web-animations keyframes (the custom properties stuff in
declaration_block.rs). That codepath is already not sound and I wanted to
get rid of it in bug 1501530, but what do I know.
* When getting an animation value from a property declaration. At that point
we no longer have the CSS rules that apply to the element to compute the
right revert value handy. It'd also use the wrong style anyway, I think,
given the way StyleBuilder::for_animation works.
We _could_ probably get them out of somewhere, but it seems like a whole lot
of code reinventing the wheel which is probably not useful, and that Blink
and WebKit just cannot implement either since they don't have a rule tree,
so it just doesn't seem worth the churn.
The custom properties code looks a bit different in order to minimize hash
lookups in the common case. FWIW, `revert` for custom properties doesn't seem
very useful either, but oh well.
Differential Revision: https://phabricator.services.mozilla.com/D21877
--HG--
extra : moz-landing-system : lando
Similar to bug 1528654, we currently bail out too early and don't process all of the correct scripts when adding breakpoints.
Differential Revision: https://phabricator.services.mozilla.com/D22355
--HG--
extra : moz-landing-system : lando
When reviewing https://bugzilla.mozilla.org/show_bug.cgi?id=1521052 I did not think about Firefox for Android which is not using e10s.
This means the main DebuggerServer will be killed when there are no connections left. Happy to discuss more about the preferred solution.
This is a regression in 66 and I hope to uplift a fix for this.
Differential Revision: https://phabricator.services.mozilla.com/D20830
--HG--
extra : moz-landing-system : lando
There is still some tight connection between ThreadClient and Target,
- Target.threadClient, which should ideally disappear in favor of
target.getFront("thread")
- Target.threadClient is manually nullified from ThreadClient.detach,
but that should disappear as well thanks to getFront.
Differential Revision: https://phabricator.services.mozilla.com/D18813
--HG--
extra : moz-landing-system : lando
A JSScript can be explicitly cloned and applied to a new realm. When this is done within the same compartment
as the original JSScript, it maintains its reference to the original ScriptSourceObject. This can lead to the
potentially surprising fact that using Debugger.findScripts({ source }) can return multiple Debugger.Script
objects representing the same function, but in multiple realms.
When we query for breakpoints in a given source, we want to take the first column breakpoint on a given line,
but that needs to apply to all potential instances of the Debugger.Script for that location, not just the first one.
Differential Revision: https://phabricator.services.mozilla.com/D20431
--HG--
extra : moz-landing-system : lando
Any time we QI to nsIFrameLoaderOwner in tests, we're really accessing
a MozFrameLoader. We don't need to be doing that anymore.
Differential Revision: https://phabricator.services.mozilla.com/D19727
--HG--
extra : moz-landing-system : lando
Evaluation of debuggee code should always begin with an empty microtask queue.
In xpcshell tests, this is not guaranteed, as it is in the web platform. This
patch changes those devtools server xpcshell tests that break this rule in a
detectable way to run the debuggee code as a separate HTML task.
In an actual browser environment, debuggee JavaScript runs as an HTML task.
Since HTML requires a microtask checkpoint at the end of each task, this means
that a debuggee task begins execution with an empty microtask queue, free of
microtasks from other tabs or the browser machinery itself. Hence, while the
debugger is pausing debuggee code, it is safe for it to save the debuggee's
microtask queue, so that those jobs do not make progress. (Which is fortunate,
because it *must* do so, lest the debuggee's microtasks run during the pause!)
In an xpcshell test, however, there is no guarantee that debuggee code begins
execution with a fresh microtask queue: the test may call `eval` or
`evalInSandbox` at any time. If such an evaluation hits a breakpoint, `debugger`
statement, etc. that invokes a Debugger hook, supervisory microtasks from the
test harness code may be set aside along with the debuggee's microtasks. If the
hook code then blocks waiting for those microtasks to run, the test will hang.
Differential Revision: https://phabricator.services.mozilla.com/D18904
--HG--
extra : moz-landing-system : lando
Making use of the new SpiderMonkey APIs for available breakpoints means
that the server needs to think a lot less about where it is pausing and
allows us to drop the concept of a pause points from the server entirely.
It is now up to SpiderMonkey to decide where it will and will not stop
when it is stepping.
Differential Revision: https://phabricator.services.mozilla.com/D17665
--HG--
extra : moz-landing-system : lando
This brings SpiderMonkey more in line with V8 for the positions that it uses for expressions
nested within statements. We generally prefer to use the expression's own location
rather than the location of the statement, in the majority of cases.
Differential Revision: https://phabricator.services.mozilla.com/D15993
--HG--
extra : moz-landing-system : lando
This patch makes it so that all target fronts inherits from a Target class mixin.
We are using a mixin as fronts should inherit from a custom Front class,
which is augmented with its own RDP request and events defined in its spec.
(This is done via FrontClassWithSpec(spec))
Depends on D15830
Differential Revision: https://phabricator.services.mozilla.com/D15831
--HG--
extra : moz-landing-system : lando
yulia
chujun
Nicolas Chevobbe
Razvan Caliman
Yura Zenevich
Michael Ratcliffe
Jason Laster
Emilio Cobos Álvarez
Andrea Marchesini
Ashley Hauck
Narcis Beleuzu
Micah Tigley
Oriol Brufau
Daniel Varga
jaril
Dorel Luca
Alexandre Poirot
Coroiu Cristina
Noemi Erli
Brian Grinstead
Julian Descottes
Brian Hackett
Andrew McCreight
Ciure Andrei
Ehsan Akhgari
Sebastian Hengst
arthur.iakab
Mats Palmgren
Edwin Gao
ravefalcon92
Razvan Maries
Logan Smyth
Brindusan Cristian
Kyle Machulis
Jim Blandy
Andrew Swan