Previously we computed a caret frame each time we started display list building for a pres shell, and tracked a stack of these as we descended through subdocuments.
This meant that we couldn't know if the caret frame had changed before we started building, and we instead had to support invalidations in the middle of building.
Since there should only ever be one focused document, we can instead retrieve this from the focus manager, and find the sole caret frame for all documents we want to paint.
Differential Revision: https://phabricator.services.mozilla.com/D33880
--HG--
extra : moz-landing-system : lando
Our ultimate goal in this bug is to include information about yields and awaits
in the completion value passed to the `onPop` handler. This means that detecting
when a frame is being suspended becomes just another step in building a
completion value. That change becomes a little clearer if those two steps happen
next to each other.
Differential Revision: https://phabricator.services.mozilla.com/D24996
--HG--
extra : moz-landing-system : lando
When a Debugger.Frame refers to a generator/async call, the generator's script
must be marked as a debuggee, so that if the call is resumed, the
JSOP_AFTERYIELD bytecode is compiled to the instrumentation that re-associates
the extant Debugger.Frame with the new concrete frame.
This extends DebugScript with a new field `generatorObserverCount`, akin to
`stepperCount`, which tracks the number of Debugger.Frames referring to the
script if it is a generator script. This count is adjusted when the
`GeneratorInfo` structure is attached to a `DebuggerFrame`, cleared, and
finalized.
Differential Revision: https://phabricator.services.mozilla.com/D32394
--HG--
extra : moz-landing-system : lando
The new export Pattern.OBJECT_WITH_EXACTLY is like the ordinary Pattern
constructor, but also fails to match if the actual value has any extra
properties.
The default behavior of object matching (to ignore additional properties) is
left unchanged, since there are too many extant tests that rely on this behavior
to be worth fixing.
Differential Revision: https://phabricator.services.mozilla.com/D32880
--HG--
extra : moz-landing-system : lando
A Debugger.Frame for a generator or async call continues to refer to the same
call across suspensions (awaits and yields). This means that, even as the
underlying concrete frames (InterpreterFrame, BaselineFrame) come and go, the
Debugger.Frame retains its relationship with a particular
AbstractGeneratorObject. When that generator is resumed, the Debugger.Frame
acquires the new concrete frame as its new referent.
Normally, when a stack frame is popped, if it had a Debugger.Frame with an
onStep handler, we decrement the frame's script's stepper count, since that
Debugger.Frame's onStep handler is obviously not going to fire any more; the
frame is dead. But in the case of a generator or async frame, the generator call
may be resumed at some point, so for such frames, we leave the script's stepper
count incremented until the generator call returns, throws, or otherwise exits
permanently.
This means that if a Debugger.Frame and its AbstractGeneratorObject are GC'd, we
must decrement the generator's script's stepper count. Of course, the script
itself may also be being GC'd, in which case we need not do anything.
This patch makes DebuggerFrame::clearGenerator solely responsible for dropping
the stepper count on generator frames. Since DebuggerFrame::finalize already
clears the frame's generator, this takes care of the stepper count automatically.
Differential Revision: https://phabricator.services.mozilla.com/D32273
--HG--
extra : moz-landing-system : lando
In later patches in the series, DebuggerFrame needs to be able to access a
generator's script even when the generator object itself is being finalized, so
it's simpler to just hold a reference to it directly.
Differential Revision: https://phabricator.services.mozilla.com/D32272
--HG--
extra : moz-landing-system : lando
Since GetGeneratorObjectForFrame is a bit involved (it looks up the identifier
'.generator' on the scope chain) and not entirely reliable (it returns nullptr
between the GENERATOR and SETALIASEDVAR .generator opcodes), it's better to
simply fetch the generator from the DebuggerFrame, when one is available.
Since a DebuggerFrame has a generator exactly when there is an entry in
generatorFrames going the other direction, from generator to DebuggerFrame, this
means that Debugger::removeFromFrameMapsAndClearBreakpointsIn can actually do
its job reliably, which lets us remove certain kinky conditions in The Famous
Step Count Assertion of 1874.
In other cases, GetGeneratorObjectForFrame is the only option, and its flakiness
doesn't matter; document those a bit better.
Differential Revision: https://phabricator.services.mozilla.com/D32271
--HG--
extra : moz-landing-system : lando
Changes include a fix for visual metrics calculations on desktop, and appending visual metrics information to gecko profiles.
Additionally, add the browsertime-results directory to gitignore.
Differential Revision: https://phabricator.services.mozilla.com/D34412
--HG--
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 adds a scalar for the codecs used when receiving and sending video in
a WebRTC call.
Differential Revision: https://phabricator.services.mozilla.com/D33840
--HG--
extra : moz-landing-system : lando
ImageBridgeChild has only one global TextureFactoryIdentifier. When WebRender is enabled, it is used for both WebRender widget and non-WebRender(BasicCompositor) widget. WebRenderImageHost and ImageHost are incompatible and WebRenderTextureHost does not permit to be consumed on compositor thread. Then it does not work well for non-WebRender widget. To address the problem at ImageContainer, ImageContainer needs to know a connected widget type. It is not easy in some cases like WebRTC. Then host side could address the problem easier.
CompositableParentManager::FindCompositable() is changed to permit transform from WebRenderImageHost to ImageHost if it is necessary when WebRenderImageHost belongs to ImageBridge.
WebRenderTextureHost is changed to permit to consume wrapped TextureHost on compositor thread. If the wrapped TextureHost is BufferTextureHost, it is possible to comsume the TextureHost on compositor and on RenderThread, since they are memory buffer or shared memory buffer. WebRTC code always create BufferTextureHost for video frame. Then it works.
Differential Revision: https://phabricator.services.mozilla.com/D34132
--HG--
extra : moz-landing-system : lando
WebExtension pages introduce a case that was previously not possible: a script
with full WebExtension privileges that runs on a page with a GeckoSession
associated to it.
This breaks the assumption that all messages from a privileged context don't
have a GeckoSession associated to it. We fix this by checking if we can find an
eventDispatcher for the given window.
This also fixes the test which had the same wrong assumption.
Differential Revision: https://phabricator.services.mozilla.com/D32512
--HG--
extra : moz-landing-system : lando
Brindusan Cristian
Yoshi Cheng-Hao Huang
Noemi Erli
Karl Tomlinson
Cosmin Sabou
Matt Woodrow
Hiroyuki Ikezoe
Jim Blandy
Nick Thomas
Yura Zenevich
Denis Palmeiro
Thomas
Zibi Braniecki
Andreea Pavel
Dan Minor
Brian Hackett
Byron Campen [:bwc]
Michael Kaply
jaril
Jonathan Kew
sotaro
Mike Conley
Alexander Surkov
Gautham Velchuru
Jared Wein
Agi Sferro
Dzmitry Malyshau