977aab16aad322fb4bd1cd0901ca07bd0ebf3035: Bug 1119462 - Allow unlimited quota for explicit persistent storage; r=bent
Jan Varga <jan.varga@gmail.com> - Fri, 09 Jan 2015 00:31:50 +0100 - rev 222736
Push
53713 by Jan.Varga@gmail.com at Thu, 08 Jan 2015 23:43:49 +0000
Bug 1119462 - Allow unlimited quota for explicit persistent storage; r=bent
eabd210312f998169d13681891a30680d170b88d: Bug 1118044, part 2 - Use GCCellPtr in NoteJSChild. r=smaug,terrence
Andrew McCreight <continuation@gmail.com> - Thu, 08 Jan 2015 15:30:54 -0800 - rev 222735
Push
53712 by amccreight@mozilla.com at Thu, 08 Jan 2015 23:31:12 +0000
Bug 1118044, part 2 - Use GCCellPtr in NoteJSChild. r=smaug,terrence
Also, strongly type the JS_TraceShapeCycleCollectorChildren function, and add an
isShape() method to GCCellPtr.
3941c5858c22c5ffc83c74ad9b4c7afb28c9ed97: Bug 1118044, part 1 - Use GCCellPtr in CycleCollectedJSRuntime::TraverseGCThing. r=smaug
Andrew McCreight <continuation@gmail.com> - Thu, 08 Jan 2015 15:30:54 -0800 - rev 222734
Push
53712 by amccreight@mozilla.com at Thu, 08 Jan 2015 23:31:12 +0000
Bug 1118044, part 1 - Use GCCellPtr in CycleCollectedJSRuntime::TraverseGCThing. r=smaug
26c24b7c06aeca5c78a26b520b916740b47c9f0b: Bug 1102631 - Create a software vsync timer. r=kats
Mason Chang <mchang@mozilla.com> - Thu, 08 Jan 2015 15:12:47 -0800 - rev 222733
Push
53711 by mchang@mozilla.com at Thu, 08 Jan 2015 23:13:06 +0000
Bug 1102631 - Create a software vsync timer. r=kats
95267af607c398fb56878d43f07c7c150dac82d7: Bug 1112480 part 10 - Mark css-animations/test_animation-pausing.html and css-transitions/test_animation-pausing.html as no longer failing; r=jwatt
Brian Birtles <birtles@gmail.com> - Fri, 09 Jan 2015 07:57:59 +0900 - rev 222732
Push
53710 by bbirtles@mozilla.com at Thu, 08 Jan 2015 22:58:29 +0000
Bug 1112480 part 10 - Mark css-animations/test_animation-pausing.html and css-transitions/test_animation-pausing.html as no longer failing; r=jwatt
With this updated approach to starting pending animations, these tests should no
longer fail on Mac 10.8 or Windows.
2081656d2497d4803e35d5962e34b2642a42e999: Bug 1112480 part 9 - Remove call to PostUpdate from AnimationPlayer::ResumeAt; r=jwatt
Brian Birtles <birtles@gmail.com> - Fri, 09 Jan 2015 07:57:58 +0900 - rev 222731
Push
53710 by bbirtles@mozilla.com at Thu, 08 Jan 2015 22:58:29 +0000
Bug 1112480 part 9 - Remove call to PostUpdate from AnimationPlayer::ResumeAt; r=jwatt
Since pending animations are no longer started outside of a style update, we no
longer need to call PostUpdate from ResumeAt.
632d54874ed20d94da6db401e3459f7b1998fd10: Bug 1112480 part 8 - Remove AnimationTimeline::FastForward; r=jwatt
Brian Birtles <birtles@gmail.com> - Fri, 09 Jan 2015 07:57:58 +0900 - rev 222730
Push
53710 by bbirtles@mozilla.com at Thu, 08 Jan 2015 22:58:29 +0000
Bug 1112480 part 8 - Remove AnimationTimeline::FastForward; r=jwatt
Now that we don't actually start pending animations until the following refresh
driver tick we no longer need to be able to fast-forward the AnimationTimeline
between ticks.
1d3d4759f4edead98212fee17aa81f26a2da08e9: Bug 1112480 part 7 - Add checking for orphaned players; r=jwatt
Brian Birtles <birtles@gmail.com> - Fri, 09 Jan 2015 07:57:58 +0900 - rev 222729
Push
53710 by bbirtles@mozilla.com at Thu, 08 Jan 2015 22:58:29 +0000
Bug 1112480 part 7 - Add checking for orphaned players; r=jwatt
When a player is made pending, we rely on it being added to a pending player
tracker that will eventually start the player. However, there are a few
situations where this might not happen. For example, we can't find a pending
player tracker (e.g. there's no source content or the source content isn't
attached to a document), or the pending player tracker disappeared.
In these cases we still want to ensure that such a player does actually get
started. This patch attempts to detect such situations and start players
accordingly.
There are, unfortunately, currently no tests for this. I have been unsuccessful
in recreating any of the situations these tests are supposed to cover.
d99b6fd9ca56842a48fd7147cecc7d0947b9cc72: Bug 1112480 part 6 - Make PendingPlayerTracker call StartOnNextTick; r=jwatt
Brian Birtles <birtles@gmail.com> - Fri, 09 Jan 2015 07:57:58 +0900 - rev 222728
Push
53710 by bbirtles@mozilla.com at Thu, 08 Jan 2015 22:58:29 +0000
Bug 1112480 part 6 - Make PendingPlayerTracker call StartOnNextTick; r=jwatt
This patch switches on the new, "actually start the player in the next refresh
driver tick" behavior. It updates PendingPlayerTracker, adding
a StartPendingPlayersOnNextTick method which calls the appropriate method on
AnimationPlayer. The existing StartPendingPlayers is renamed to
StartPendingPlayersNow and is used for testing only.
Furthermore, since we now expect AnimationPlayer::StartOnNextTick to be
functional, AnimationPlayer::DoPlay is updated to use it when there is no
document available. This should make playing an animation player always
asynchronous, that is, always transition to the pending state temporarily
(unless we are already playing).
003c367a510f7396f172c6f48d2bd99ed7d42248: Bug 1112480 part 5 - Add AnimationTimeline::IsUnderTestControl; r=jwatt
Brian Birtles <birtles@gmail.com> - Fri, 09 Jan 2015 07:57:58 +0900 - rev 222727
Push
53710 by bbirtles@mozilla.com at Thu, 08 Jan 2015 22:58:29 +0000
Bug 1112480 part 5 - Add AnimationTimeline::IsUnderTestControl; r=jwatt
Earlier in this patch series we added AnimationPlayer::StartOnNextTick which
takes a ready time parameter expressed in timeline time. In order to call this
method when painting finishes we need to convert the TimeStamp recorded when
painting finished to a timeline time. However, when the timeline is driven by
a refresh driver under test control we can no longer meaningfully do this
conversion since there is no correspondence between the notion of time used to
record the time when painting finished (wallclock time) and the notion of time
used by the timeline (which has been arbitrarily adjusted by test code).
We need a way to detect this situation so that we know not to call
ToTimelineTime in that case.
Alternatively, we could make ToTimelineTime automatically return a null value
when its refresh driver is under test control. However, in this situation
ToTimelineTime can still actually be used to convert a TimeStamp to a timeline
time as long as the TimeStamp is from the same refresh driver. Indeed,
GetCurrentTime does exactly that. So if we were to go down that route we would
have to provide a way for GetCurrentTime to work around that restriction.
For now, this patch puts the onus on the caller of ToTimelineTime to check if
the timeline is under test control first (unless they are passing a TimeStamp
from the same refresh driver, in which case there is no need to check).
69a084bd65e4fe5a47f6d4f36f3dccfb126c975b: Bug 1112480 part 4 - Use mPendingReadyTime in AnimationPlayer::Tick; r=jwatt
Brian Birtles <birtles@gmail.com> - Fri, 09 Jan 2015 07:57:58 +0900 - rev 222726
Push
53710 by bbirtles@mozilla.com at Thu, 08 Jan 2015 22:58:29 +0000
Bug 1112480 part 4 - Use mPendingReadyTime in AnimationPlayer::Tick; r=jwatt
This patch makes AnimationPlayer act on requests to StartOnNextTick by checking
for mPendingReadyTime on each tick.
We also check that the ready time is not in the future since currently it might
be possible that we get multiple calls to AnimationPlayer::Tick within a single
refresh driver tick.
Note that this patch shouldn't actually produce any observable change yet,
however, since we don't call StartOnNextTick anywhere.
73091940bedfc769250e199d9489e3545ccf235e: Bug 1112480 part 3 - Add AnimationPlayer::StartOnNextTick; r=jwatt
Brian Birtles <birtles@gmail.com> - Fri, 09 Jan 2015 07:57:58 +0900 - rev 222725
Push
53710 by bbirtles@mozilla.com at Thu, 08 Jan 2015 22:58:29 +0000
Bug 1112480 part 3 - Add AnimationPlayer::StartOnNextTick; r=jwatt
Adds a method that schedules an animation player to begin on the next tick using
the supplied time as the start time.
We don't call this yet, however, but simply add the method and the
mPendingReadyTime member it sets.
dfba5219541ff18c96f1b43e52f4d54bd4bc707d: Bug 1112480 part 2 - Factor out ResumeAt; r=jwatt
Brian Birtles <birtles@gmail.com> - Fri, 09 Jan 2015 07:57:58 +0900 - rev 222724
Push
53710 by bbirtles@mozilla.com at Thu, 08 Jan 2015 22:58:29 +0000
Bug 1112480 part 2 - Factor out ResumeAt; r=jwatt
In addition to AnimationPlayer::StartNow, this patch series also makes
AnimationPlayer::Tick start animations.
Since these methods will share a lot of code we first factor out a common
ResumeAt method to encapsulate the common code.
15f5148fe5892f1267f298ea6a09d8a6f64dc647: Bug 1112480 part 1 - Adjust tests to accommodate changed animation start behavior; r=jwatt
Brian Birtles <birtles@gmail.com> - Fri, 09 Jan 2015 07:57:58 +0900 - rev 222723
Push
53710 by bbirtles@mozilla.com at Thu, 08 Jan 2015 22:58:29 +0000
Bug 1112480 part 1 - Adjust tests to accommodate changed animation start behavior; r=jwatt
In this patch series we adjust the behavior of animation starting so that the
animation does not actually start until the following refresh driver tick. This
requires some tweaks to tests to ensure they continue to pass.
7877a00d7025405b31b2f0df73e8a1067bda5923: Backout 51e4e9fcde24 (bug 1105895) for causing some Octane and Dromaeo regressions.
Nicholas Nethercote <nnethercote@mozilla.com> - Thu, 08 Jan 2015 14:19:36 -0800 - rev 222722
Push
53709 by nnethercote@mozilla.com at Thu, 08 Jan 2015 22:48:10 +0000
Backout 51e4e9fcde24 (
bug 1105895) for causing some Octane and Dromaeo regressions.
06402d84ac3d38c86214129c533911a520165e58: Bug 1119060: Ensure that PluginProcessParent::mLaunchCompleteTask is non-null until the runnable has executed; r=gfritzsche
Aaron Klotz <aklotz@mozilla.com> - Wed, 07 Jan 2015 18:01:51 -0700 - rev 222721
Push
53708 by aklotz@mozilla.com at Thu, 08 Jan 2015 22:46:03 +0000
Bug 1119060: Ensure that PluginProcessParent::mLaunchCompleteTask is non-null until the runnable has executed; r=gfritzsche
20a7f674d668fdd19e0337f6f5847befc3a66fbf: Bug 1110585 - Inconsistent timestamp in storage metadata file; r=bent
Jan Varga <jan.varga@gmail.com> - Thu, 08 Jan 2015 23:38:53 +0100 - rev 222720
Push
53707 by Jan.Varga@gmail.com at Thu, 08 Jan 2015 22:39:24 +0000
Bug 1110585 - Inconsistent timestamp in storage metadata file; r=bent
86f3f3bee063e719039107fb7a04c0b98b384c92: bug 1101194 - follow-up to fix bustage in TestCertDB r=bustage on a CLOSED TREE
David Keeler <dkeeler@mozilla.com> - Thu, 08 Jan 2015 10:56:07 -0800 - rev 222719
Push
53706 by dkeeler@mozilla.com at Thu, 08 Jan 2015 18:58:50 +0000
bug 1101194 - follow-up to fix bustage in TestCertDB r=bustage on a CLOSED TREE
Turns out there was a code path that resulted in attempting to acquire a lock
on the DataStorage mutex when one had already been acquired, resulting in
deadlock. This fixes it.
fec317aa00bc9d1d71beb664237bd659a256a7f2: Bug 1107731, upgrade Mozilla 37 to use NSS 3.18 (this is beta 5), r=wtc
Kai Engert <kaie@kuix.de> - Thu, 08 Jan 2015 19:40:05 +0100 - rev 222718
Push
53705 by kaie@kuix.de at Thu, 08 Jan 2015 18:40:15 +0000
Bug 1107731, upgrade Mozilla 37 to use NSS 3.18 (this is beta 5), r=wtc
839a5e109b3580f1b932e02c1cd9e8eb725fa8a9: Bug 1118534 - Comment updates in nsIContentPolicy, nsIOService.idl, nsNetutil.h, NetUtil.jsm (r=sicking)
Christoph Kerschbaumer <mozilla@christophkerschbaumer.com> - Tue, 06 Jan 2015 17:01:07 -0800 - rev 222717
Push
53704 by mozilla@christophkerschbaumer.com at Thu, 08 Jan 2015 18:34:34 +0000
Bug 1118534 - Comment updates in nsIContentPolicy, nsIOService.idl, nsNetutil.h, NetUtil.jsm (r=sicking)