These builds aren't ready for general availability, so we don't want to publish
them. But we want to start building them now.
Differential Revision: https://phabricator.services.mozilla.com/D17453
--HG--
extra : moz-landing-system : lando
The current document of a window can change in between the time when a
PaymentRequest registers as an activity observer and when it attempts
to unregister, so keep a strong reference to the document. This is the
same issue as bug 1317805.
Differential Revision: https://phabricator.services.mozilla.com/D17540
--HG--
extra : moz-landing-system : lando
The GeckoView test app doesn't handle visited link history, so disable
a couple tests that rely on that.
Differential Revision: https://phabricator.services.mozilla.com/D17698
--HG--
extra : moz-landing-system : lando
I am bit surprised myself, but just removing the getPropertyDescriptor trap seems to mostly work.
The only real special case here is the XPC Sandbox, which I changed to keep using its getPropertyDescriptorImpl.
testSetPropertyIgnoringNamedGetter.cpp didn't even really need its getPropertyDescriptor implementation.
Differential Revision: https://phabricator.services.mozilla.com/D17386
--HG--
extra : moz-landing-system : lando
The interpreter will use this to set the frame's ICEntry* pointer at jump target
ops and then it will just bump this pointer after each JOF_IC op. This way the
interpreter can use Baseline ICs with minimal overhead compared to the Baseline
JIT.
Differential Revision: https://phabricator.services.mozilla.com/D17115
--HG--
extra : moz-landing-system : lando
The bytecode emitter used to call checkTypeSet for each JOF_TYPESET op. Despite
correctness asserts in the TypeScript code, this was pretty error prone. Doing
something similar for JOF_IC ops would have made it worse.
The solution is to move this check to BytecodeEmitter::emitCheck (called for
each opcode we emit), so we don't have to worry about this anymore.
Differential Revision: https://phabricator.services.mozilla.com/D17114
--HG--
extra : moz-landing-system : lando
I don't know why this check was ever added. A comment here suggests we expected
irrelevant animations to be removed from their timeline:
https://hg.mozilla.org/mozilla-central/rev/8406c5300ab7051ae6fe9bf41a1d30261cf70a4a#l2.16
Furthermore, a comment in the changeset description for that same changeset
suggests that to be the case:
"For example, if a CSS animation is finished (IsRelevant() == false so that
animation will have been removed from the timeline)"
Another comment removed in that patch has:
"Note that we only store relevant animations on the timeline since they are
the only ones that need ticks and are the only ones returned from
AnimationTimeline::GetAnimations"
which suggests it was added a point when we had a GetAnimations() method on
AnimationTimeline and hence it was needed for that.
The other possibility is that we were preempting a point when timelines would
switch between being active and inactive:
"FIXME: Once we expect animations to go back and forth betweeen being inactive
and active, we will need to store more than just relevant animations on the
timeline. This is because an animation might be deemed irrelevant because its
timeline is inactive. If it is removed from the timeline at that point the
timeline will have no way of getting the animation to add itself again once it
becomes active."
Indeed, we might need this for ScrollTimelines. For now, however, it seems
unnecessary (a try run with simply this check removed passes all test).
(Furthermore, in bug 1253476 or one of its dependencies, this check will prevent
us from combining filling animations since the original (filling) animations
will be kept alive by the timeline. Should this indeed prove necessary for bug
1253476, that bug will add an automated test that will fail if we re-introduce
this condition.)
Differential Revision: https://phabricator.services.mozilla.com/D17798
--HG--
extra : moz-landing-system : lando
Move CaptureStateForFramesOf into ContentRemoved, so we can traverse frames
which were under display: contents as well.
Differential Revision: https://phabricator.services.mozilla.com/D15319
--HG--
extra : moz-landing-system : lando
Depends on D17630
I am not mentioning the original test in the test file because they are not similar.
Original test was not actually testing anything interesting for us.
Differential Revision: https://phabricator.services.mozilla.com/D17631
--HG--
extra : moz-landing-system : lando
Add tests that check serialization and deserialization for indefinite script timeout
Differential Revision: https://phabricator.services.mozilla.com/D17148
--HG--
extra : moz-landing-system : lando
