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
The aborted-sessions ping is written periodically, even when Telemetry
upload is enabled (and thus the profile has a canary client ID).
On later starts, if this file exists, it is read and send if upload is enabled
(which could have happened in the previous session or by changing prefs.js).
If we now detect that it contains the canary client ID we avoid sending it
and simply remove the file from disk.
Differential Revision: https://phabricator.services.mozilla.com/D17350
--HG--
extra : moz-landing-system : lando
`Enter` will search for the next occurrence of the "Find" string.
`Shift+Enter` will search for the previous occurrence of the "Find" string.
For this, FindInPageBar will intercept all `onKey` events and
- on `KeyEvent.ACTION_DOWN` will consume `Shift+Enter` which would otherwise
insert a newline character in the search box
- on `KeyEvent.ACTION_UP` will do a new next/previous search depending on the
keys pressed.
Differential Revision: https://phabricator.services.mozilla.com/D17133
--HG--
extra : moz-landing-system : lando
With the per-track pulling settings we have today it is clearly the intention
of the producer to start consuming a track that has pulling enabled, even if
there are other tracks where pulling is disabled.
This patch fixes that, so that when a stream has at least one pulled track it
will append null data to other tracks (commonly video) if they are lacking
data.
This means that we still block an entire stream if all tracks have pulling
disabled - to maintain the status quo for media element capture, which is
the only push-only producer of data.
Differential Revision: https://phabricator.services.mozilla.com/D17611
--HG--
extra : moz-landing-system : lando
We reject MSVC compilers < 2017 already, there's no point checking for
smaller versions after that.
Differential Revision: https://phabricator.services.mozilla.com/D17770
--HG--
extra : moz-landing-system : lando
These days for the types we share computed value representation we don't really
need any special code.
Differential Revision: https://phabricator.services.mozilla.com/D17763
--HG--
extra : moz-landing-system : lando
This lets us avoid drawing the complete input for ever tile when
drawing filters into a tile.
Differential Revision: https://phabricator.services.mozilla.com/D17686
--HG--
extra : moz-landing-system : lando
This will change a bit in the future but I think this is a reasonable
initial version.
Differential Revision: https://phabricator.services.mozilla.com/D16801
--HG--
extra : moz-landing-system : lando
