This patch is a fairly minimal rename of the AnimationPlayer interface. It
leaves a bunch of local variables and helper classes still using the word
"player". These will be addressed in subsequent patches that don't require DOM
peer review.
--HG--
rename : dom/animation/AnimationPlayer.cpp => dom/animation/Animation.cpp
rename : dom/animation/AnimationPlayer.h => dom/animation/Animation.h
rename : dom/webidl/AnimationPlayer.webidl => dom/webidl/Animation.webidl
We define KeyframeEffectReadonly in KeyframeEffect.cpp since Web Animations also
defines KeyframeEffect and when we come to implement that I expect we'll define
it in the same class, maybe even using the same object.
This patch also adds a few missing includes in places where
KeyframeEffectReadonly is used so that we're not just cargo-culting it in.
--HG--
rename : dom/animation/Animation.cpp => dom/animation/KeyframeEffect.cpp
rename : dom/animation/Animation.h => dom/animation/KeyframeEffect.h
rename : dom/animation/test/css-animations/test_animation-name.html => dom/animation/test/css-animations/test_effect-name.html
rename : dom/animation/test/css-animations/test_animation-target.html => dom/animation/test/css-animations/test_effect-target.html
rename : dom/animation/test/css-transitions/test_animation-name.html => dom/animation/test/css-transitions/test_effect-name.html
rename : dom/animation/test/css-transitions/test_animation-target.html => dom/animation/test/css-transitions/test_effect-target.html
rename : dom/webidl/Animation.webidl => dom/webidl/KeyframeEffect.webidl
Most of this is fairly obvious. However, the addition of 'override' to
ElementPropertyTransition::Name() is not strictly necessary. It was simply added
because while making these changes I accidentally dropped the 'virtual' keyword
from the method in the superclass and the compiler didn't complain. Adding this
will hopefully make it harder to create the same bug in the future.
--HG--
rename : dom/animation/test/css-animations/test_animation-effect-name.html => dom/animation/test/css-animations/test_animation-name.html
rename : dom/animation/test/css-transitions/test_animation-effect-name.html => dom/animation/test/css-transitions/test_animation-name.html
This is more likely to be correct, and a necessary step in case we ever want
to move to Object.is.
This keeps ise as an alias for is, and introduces is_loosely for the old
behaviour.
A no-cors mode request should not go through a nsCORSProxyListener, which can only handle same-origin and cors mode.
The test for no-cors was passing allowOrigin, which was converting it into a CORS request, which is why it was passing.
I also realized that it is port 8888 and not 8000, so fixed that in some of the redirect tests.
--HG--
extra : rebase_source : a959877e9fc65ae177dfd480258d164d7b2e6af5
Installing a Webapp is an asynchronous job, and there is a pocket of time
between when web content requests to install an app and before the browser
displays an installation prompt that the outer window of the content can
browse away. This pocket of time is typically used by XHR to request the
web app resources and verify their contents.
This pocket of time is, essentially, bug 771294, and is a bit of a security
problem.
This problem was originally patched over on Desktop by checking in the parent
process that the outer window was still at the same URI as it had been when it
made the request. I'm not entirely sure if Android / B2G made similar checks.
With separated content processes, however, the browser front-end can no longer
performantly check to ensure that the outer window is at the same URI.
We solve this problem by sending up a message in the content process when
the location of an outer window making use of navigator.mozApps changes.
We hold a Map of "actions" mapping to in-flight installs mapped by the
outer window ID of the requesting content. When we notice a location
change, we mark those actions as cancelled. When the XHR returns, we have
it check the state of its actions, and if they're cancelled, it aborts
further action.
Normally, this wouldn't be necessary, since any XHR initiated by the
content window would be cancelled once the location changed, but in
this case, the XHR is occurring in Webapps.jsm, and is not influenced
by the outer window of the content.
--HG--
extra : rebase_source : 5f95002a21c96c5cbf3dca8ca265400448251b43