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
Currently git for Windows converts LF to CRLF by default, so this change prevents that to match the mercurial behavior.
Differential Revision: https://phabricator.services.mozilla.com/D32001
--HG--
extra : moz-landing-system : lando
When window is resized, the cue would usually be zoomed in or out automatically with the video and keep its relative position to video.
However, if video is being applied the explicit percentage value on its 'width' or 'height', we have to recompute cue's position in this situation, because the width or height of the video would be scaled again after applied the first size scaled which is caused by resizing.
Differential Revision: https://phabricator.services.mozilla.com/D36138
--HG--
extra : moz-landing-system : lando
Change the `ResultImplementation` and `Result` constructors to accept success
values by `const` reference. This makes it possible for `Result` to carry
`MOZ_NON_PARAM` types as success values.
Differential Revision: https://phabricator.services.mozilla.com/D36682
--HG--
extra : moz-landing-system : lando
