According to the spec, negative values are valid for polygon(), so we should not
clamp it while computing and serializing negative calc values for polygon().
MozReview-Commit-ID: 5uhLjoYmJEh
--HG--
extra : rebase_source : e314736bff61a4ea881ea0182fa1362fe621a1b2
nsComputedDOMStyle::SetCssTextToCoord() is a helper function for computing and
serializing a nsStyleCoord. In the current implementation, SetCssTextToCoord
implicitly clamp negative calc values, which is pretty non-trivial.
In this patch, we expose an extra aClampNegativeCalc parameter for SetCssTextToCoord,
so the callers can explicitly set the clamping mode as needed.
MozReview-Commit-ID: IOIhssjUldC
--HG--
extra : rebase_source : 44d9ff3a5fc20a869de356868688483aa28ecff8
We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.
Our existing content policy implementations which require or expect a loading
principal currently retrieve it from the context node. Since no current
callers require the principal to be the loading principal, and some already
expect it to be the triggering principal (which there's currently no other way
to retrieve), I chose to pass the triggering principal whenever possible, but
use the loading principal to determine the origin URL.
As a follow-up, I'd like to change the nsIContentPolicy interface to
explicitly receive loading and triggering principals, or possibly just
LoadInfo instances, rather than poorly-defined request
origin/principal/context args. But since that may cause trouble for
comm-central, I'd rather not do it as part of this bug.
MozReview-Commit-ID: LqD9GxdzMte
--HG--
extra : rebase_source : 41ce439912ae7b895e0a3b0e660fa6ba571eb50f
After bug 1401825, we no longer need the code for text-shadow anymore,
so we can just remove it.
MozReview-Commit-ID: B2zpzetwW91
--HG--
extra : rebase_source : 655ef8f1fc646b3905c55199b5f509c8e4093ddb
As explained in the extended comment in this patch, for Servo we want to post
restyles when creating new animations so that we run a second animation
restyle and incorporate the result of new animations into style immediately.
(Gecko does everything in the one restyle, and although this causes other bugs
related to triggering transitions, at least it means it does not require
restyles to be posted here).
It turns out that we normally end up posting a restyle anyway in
CSSAnimation::SetAnimationIndex. Bug 1332958 was supposed to drop that but it
never landed.
However, CSSAnimation::SetAnimationIndex only posts a restyle when there is
a change to the animation index. It turns out that, by chance, there normally
*is* a change to a CSSAnimation's animation index when it is created. Initially
it takes its animation index from Animation::sNextAnimationIndex which is
incremented each time it is assigned to an animation.
If the first Animation we create for a given content process is a CSSAnimation
then sNextAnimationIndex will be zero and so we will initially assign an
animation index of zero. If that CSS animation is also the first in the list
of animations in animation-name, when we call SetAnimationIndex we will pass
zero as the index to use, and when we go to update the animation index we will
detect that there is no change, and will NOT post an animation restyle.
As a result the target element's style will NOT reflect the animated style.
To fix this we need to ensure that *new* CSS animations trigger a restyle.
For *changes* to animations, the corresponding calls to SetKeyframes and
SetSpecifiedTiming post restyles so the behavior should be correct in those
cases.
For *removed* animations I observed that in at least some cases we successfully
post a restyle. However, this appeared to be as much by chance as anything so
this patch also posts a restyle for removed animations. (Note that the
EffectCompositor will ignore redundant restyle requests so this is ok.)
This patch deliberately does not expose Animation::PostUpdate and call that
because the code introduced here is intended to be temporary. Long-term we
should remove the Gecko style backend and allow the calls to PlayFromStyle,
PauseFromStyle, CancelFromStyle etc. to post restyles just like calls to Play,
Pause, and Cancel do. At that point this code can also be removed.
MozReview-Commit-ID: 4c3vJdLBqeY
--HG--
extra : rebase_source : 684cb483562709161b2d5635e173e55319509a70
All our widgets support it with a constant true.
MozReview-Commit-ID: JMEItUsxYWq
--HG--
extra : rebase_source : e7e0a3f83001813239338bc5b3895252e1fb3ea6
Note: `cssMessages.js` changes were generated by running
`mach test devtools/client/webconsole/new-console-output/test/fixtures/stub-generators/browser_webconsole_update_stubs_css_message.js`
MozReview-Commit-ID: 4UHmHcC5eWm
--HG--
extra : rebase_source : 9ff1f1966f46968865084a24a00dd3a69b52e73b
In this patch, we add 3 tests:
1. test for blocked domain
2. test for blocked sub-domain
3. test for non-blocked domain
MozReview-Commit-ID: JzMImsbGoPr
--HG--
extra : rebase_source : 0eed42f6d2815bd8adbb9fb6be54b6feb3b1bcc8
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Sebastian Hengst
Cameron McCormack
Emilio Cobos Álvarez
Jeremy Chen
Xidorn Quan
Phil Ringnalda
Kris Maglione
J. Ryan Stinnett
Brian Birtles
Ryan VanderMeulen
Hiroyuki Ikezoe
Bobby Holley
Simon Sapin
Nicholas Nethercote
Manish Goregaokar