it's very helpful to see the list of clips and the way they affect a chased primitive
Example:
```
building clip chain instance with local rect TypedRect(1561.0×1968.0 at (-300.0,-300.0))
clip Rectangle(3840.0×1874.0, Clip) at (0.0,0.0) in space SpatialNodeIndex(1)
flags (empty), resulted in Partial
clip Rectangle(3840.0×1874.0, Clip) at (0.0,0.0) in space SpatialNodeIndex(2)
flags (empty), resulted in Partial
```
Differential Revision: https://phabricator.services.mozilla.com/D37137
--HG--
extra : moz-landing-system : lando
DebuggerFrame::eval and DebuggerObject::evalInGlobal are two more invocation
functions that can reasonably use Completion to report the results of the
operation.
Differential Revision: https://phabricator.services.mozilla.com/D33077
--HG--
extra : moz-landing-system : lando
Replacing more calls to Debugger::resultToCompletion with uses of the newer API.
Differential Revision: https://phabricator.services.mozilla.com/D33076
--HG--
extra : moz-landing-system : lando
Use the `Completion` type to report the result of the
`DebuggerObject::setProperty` and `getProperty` methods.
Differential Revision: https://phabricator.services.mozilla.com/D25097
--HG--
extra : moz-landing-system : lando
This patch introduces a new type to the debugger, `js::Completion`, describing
how a given JavaScript evaluation completed. It's a wrapper around a `Variant`
with alternatives:
- Return
- Throw
- Terminate
- InitialYield (the initial yield of a generator, returning the generator object)
- Yield (subsequent yields of a generator)
- Await (both initial and subsequent)
We can construct a `Completion` in two ways:
- From any JavaScript operation's result (a success value and a context carrying
an exception value and stack). This only distinguishes between Return, Throw,
and Terminate.
- From a stack frame that's about to be popped. This allows us to identify
yields and awaits.
Given a `Completion` we can construct Debugger API 'completion values' to pass
to hooks, as well as the resumption/value/context states that tell the engine
how to continue execution. Within Debugger itself, `Completion` values are a
convenient place to gather up various bits of logic: identifying suspensions,
chaining resumption values from multiple Debugger hooks, and so on.
Although `Completion` should be used throughout Debugger, this patch only uses
it for the `onPop` hook. Subsequent patches in the series will apply it to other
cases where Debugger can invoke JavaScript.
Differential Revision: https://phabricator.services.mozilla.com/D24997
--HG--
extra : moz-landing-system : lando
Already tested via toolbox menus in devtools/client/framework/test/browser_toolbox_zoom_popup.js
Could open a follow up to allow for other anchor points than bottom-left.
Differential Revision: https://phabricator.services.mozilla.com/D37044
--HG--
extra : moz-landing-system : lando
We were clearing the completion text all the time to prevent
a visual glitch while typing (See Bug 1491776). But since we
are now waiting for 75ms before calling the autocomplete
function (which triggers the autocompletion text update), we
have a flash of the completion text, which isn't ideal.
In this patch, we check if the typed letters match the begining
of the completion text, and if they do, we don't clear the
completion text.
In the same time, we set the completion text in absolute position
so it doesn't jump when the new letter is added in the CodeMirror
document.
Finally, we change how the Editor pipe events from CodeMirror to
include parameters, so we can use them in JsTerm.
Differential Revision: https://phabricator.services.mozilla.com/D36163
--HG--
extra : moz-landing-system : lando
DebuggerFrame::eval and DebuggerObject::evalInGlobal are two more invocation
functions that can reasonably use Completion to report the results of the
operation.
Differential Revision: https://phabricator.services.mozilla.com/D33077
--HG--
extra : moz-landing-system : lando
Replacing more calls to Debugger::resultToCompletion with uses of the newer API.
Differential Revision: https://phabricator.services.mozilla.com/D33076
--HG--
extra : moz-landing-system : lando
Use the `Completion` type to report the result of the
`DebuggerObject::setProperty` and `getProperty` methods.
Differential Revision: https://phabricator.services.mozilla.com/D25097
--HG--
extra : moz-landing-system : lando
This patch introduces a new type to the debugger, `js::Completion`, describing
how a given JavaScript evaluation completed. It's a wrapper around a `Variant`
with alternatives:
- Return
- Throw
- Terminate
- InitialYield (the initial yield of a generator, returning the generator object)
- Yield (subsequent yields of a generator)
- Await (both initial and subsequent)
We can construct a `Completion` in two ways:
- From any JavaScript operation's result (a success value and a context carrying
an exception value and stack). This only distinguishes between Return, Throw,
and Terminate.
- From a stack frame that's about to be popped. This allows us to identify
yields and awaits.
Given a `Completion` we can construct Debugger API 'completion values' to pass
to hooks, as well as the resumption/value/context states that tell the engine
how to continue execution. Within Debugger itself, `Completion` values are a
convenient place to gather up various bits of logic: identifying suspensions,
chaining resumption values from multiple Debugger hooks, and so on.
Although `Completion` should be used throughout Debugger, this patch only uses
it for the `onPop` hook. Subsequent patches in the series will apply it to other
cases where Debugger can invoke JavaScript.
Differential Revision: https://phabricator.services.mozilla.com/D24997
--HG--
extra : moz-landing-system : lando
There are some intermittent failures in xpcshell tests (eg bug 1562344)
in the new emulator; let's revert to the older emulator until those can
be figured out.
Differential Revision: https://phabricator.services.mozilla.com/D37110
--HG--
extra : moz-landing-system : lando
This patch also fixes the Home and Sidebar Touch Bar buttons, since using them after customizing showed that they no longer worked.
Differential Revision: https://phabricator.services.mozilla.com/D35085
--HG--
extra : moz-landing-system : lando
This is both simpler and faster than the old scheme where the pc was stored in
a register but could be clobbered by R2.
On x64 this wins about 9-10%. On 32-bit x86 we don't have enough registers so
there we load the pc from the frame in more cases. That's about a 2-3%
regression and is a reasonable trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D36583
--HG--
extra : moz-landing-system : lando
After the recent script data changes we can now read objects/scopes/bigints and resume offsets
from JIT code.
Differential Revision: https://phabricator.services.mozilla.com/D36201
--HG--
extra : moz-landing-system : lando
Stop inserting DebuggeeFrameGeneratorScript keys in the cross-compartment
wrapper table for the edges from Debugger.Frames for generator / async calls to
the generators' scripts. The wrappers are unnecessary, and since they're not
unique when multiple Debugger.Frames refer to different calls of the same
generator, we can't easily tell when to remove them.
Differential Revision: https://phabricator.services.mozilla.com/D35617
--HG--
extra : moz-landing-system : lando
Jason Laster
Jared Wein
Andreea Pavel
Ciure Andrei
Dzmitry Malyshau
Jim Blandy
Julian Descottes
Honza Bambas
Nicolas Chevobbe
Dorel Luca
Geoff Brown
Kershaw Chang
harry
Panos Astithas
Coroiu Cristina
Mathieu Leplatre
Andrea Marchesini
Yash Johar
Jan de Mooij
Sylvestre Ledru
Emilio Cobos Álvarez
Paul Adenot
Kagami Sascha Rosylight