This follows from the previous patch; these values feed into UpdateMinMaxScale
as well, which explicitly wants to use floats, so there's no point in creating
doubles. The source of this information is also a float-based matrix.
MozReview-Commit-ID: LPk4Xm9AaJJ
--HG--
extra : rebase_source : d7714755fb1078880133d6f044cc9bc7743439ee
That way we don't bust the build (for some reason the ASAN build choked in
ResponsiveImageSelector, I suspect due to missing includes).
MozReview-Commit-ID: 6I6Q7jiAFr0
This needs to dumb down the parsing in order to match what we do in Gecko and
pass more tests.
The remaining tests are just because of calc() in media queries and "or" media
expressions.
MozReview-Commit-ID: CXGdYVbojBL
Add an intermediate step in old-configure.in for setting up
BINDGEN_CFLAGS (renamed to BINDGEN_SYSTEM_FLAGS), so we can add whatever
flags we like (e.g. for system libaries with their includes in
non-standard places) at a later point.
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
This case is hit by hovering over menu items, so the optimization is somewhat worthwhile.
As a side-effect, not causing reflows also avoids a XUL <select> popup positioning bug.
MozReview-Commit-ID: AOrijytoHHL
--HG--
extra : rebase_source : c2156eb24171f6d0b0e5476c4a7dbc641a0b5301
Based on patch by Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: 26IV2A3vZAB
--HG--
extra : rebase_source : a4cbcafc8a8e8539b8275e5d0dfdff55175cc882
Based on patch by Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: 91pyS53yTVt
--HG--
extra : rebase_source : 7418ba9f83075211f2a8d9b0ef85039684e78121
As Xidorn mentions, if the plan is stylo-in-chrome for 59, we really should land
this assertion pretty much now. This ensures that we don't ship 58 without this
hack.
MozReview-Commit-ID: JXol2r3BMtC
Based on patch by Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: 26IV2A3vZAB
--HG--
extra : rebase_source : a4cbcafc8a8e8539b8275e5d0dfdff55175cc882
Based on patch by Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: 91pyS53yTVt
--HG--
extra : rebase_source : 7418ba9f83075211f2a8d9b0ef85039684e78121
Constified enums are default now. I think I want to introduce an option to
bindgen to allow setting the default enum behavior, but it doesn't need to block
this.
The ServoBindings.toml changes are somewhat hacky, but that's because of
https://github.com/rust-lang-nursery/rust-bindgen/issues/1125.
Also, the fixups now need to account for whitespace, since quote generates stuff
like root :: nsString, and we don't rustfmt the bindings if there's no rustfmt
installed.
MozReview-Commit-ID: FZOvZnfYXj5
--HG--
extra : rebase_source : 6cda8e65315d97f394ed2441dd882b6ff955efae
Bindgen now assumes for replaced types that all the template parameters are
used, which makes sense.
We don't use the Deleter, so let's get rid of it.
MozReview-Commit-ID: AXxRgyLorD7
--HG--
extra : rebase_source : 844691924cbe692deceeda79d031d9f95bd4f33f
And remove unreachable code after MOZ_CRASH_UNSAFE_OOL().
MOZ_CRASH_UNSAFE_OOL causes data collection because crash strings are annotated to crash-stats and are publicly visible. Firefox data stewards must do data review on usages of this macro. However, all the crash strings this patch collects with MOZ_CRASH_UNSAFE_OOL are already collected with NS_RUNTIMEABORT.
MozReview-Commit-ID: IHmJfuxXSqw
--HG--
extra : rebase_source : 031f30934b58a7b87f960e57179641d44aefe5c5
extra : source : fe9f638a56a53c8721eecc4273dcc074c988546e
And remove unreachable code after MOZ_CRASH().
MozReview-Commit-ID: 6ShBtPRKYlF
--HG--
extra : rebase_source : 0fe45a59411bda663828336e2686707b550144ae
extra : source : 8473fd7333d2abe1ea1cc176510c292a5b34df45
Just notice these precision errors are fixed by our other patches (i.e.
not by this patch series). Anyway, it's time to remove the tolerance.
MozReview-Commit-ID: 2ZDoRhuVOL8
--HG--
extra : rebase_source : 585ddcc4640ef9c8f5875d586e371b101626505d
Use the new added FFI, Servo_ComposeAnimationSegment, to compose an
animation segment from Servo backend on the compositor.
MozReview-Commit-ID: LNgpCSIlDl9
--HG--
extra : rebase_source : 5b5c145fae877b4f4b01ea54259737dc9dad2951
We will use Servo backend on the compositor, so implement this for opacity.
MozReview-Commit-ID: BeWR2nBSbjb
--HG--
extra : rebase_source : eb5db3cf04640a83f13857984e792a949f26bcc7
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
We have a fair number of files that have a particular stale version of the MPL
boilerplate. (It was probably originally correct, and then the official
boilerplate changed, and the stale MPL boilerplate continued to propagate via
copypasting from neighboring files into newly-added files.)
This patch updates this stale MPL text (and *only* the MPL text) to the latest
version, which can be found at https://www.mozilla.org/en-US/MPL/headers/ and
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
MozReview-Commit-ID: 8WeBb8b0uRo
--HG--
extra : rebase_source : 2c3aa8d07ba23714501c9e26ad03625aeab36a7a
(This brings these lines into conformance with our standard style for mode
lines, and it's required in order for the modeline.py script to be able to
process these files.)
MozReview-Commit-ID: KqppMKF1jHv
--HG--
extra : rebase_source : 831b29574d66b66b8104f29b5b5c538241e95eba
Note that I'm intentionally *not* leaving a blank line between the license
block and the "IWYU pragma" line, in nsDisplayItemTypesList.h. This matches the
prevailing style that I found in other files that have "IWYU pragma" lines.
I copied the boilerplate comment directly from the Coding Style MDN page:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
MozReview-Commit-ID: ACoHkDFe8Z3
--HG--
extra : rebase_source : 374d28fea72cfb76043bde724120877b15092d01
It's a sub-class of nsAtom, useful for cases where you know you are dealing
exclusively with static atoms. The nice thing about it is that you can use
raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release
implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.)
MozReview-Commit-ID: 4Q6QHX5h44V
--HG--
extra : rebase_source : e4237f85b4821b684db0ef84d1f9c5e17cdee428
layout/style/crashtests/439184-1.html is too slow (over 12min) on debug build of
android/stylo.
MozReview-Commit-ID: JHD6mZW7M4E
--HG--
extra : rebase_source : d6c1e4d6b9ee65ffe3e4e2a9931047d28d7d463d
This fixes multiple things:
* EffectCompositor was using the light tree instead of the flat tree.
* When we insert an element inside the document, we may not style it right away
(we mark it for lazy frame construction with the NODE_NEEDS_FRAME). Since we
trigger animations and transitions from the traversal, we can't skip flushing
if we call getComputedStyle on any of those.
MozReview-Commit-ID: DpAhmLH3uJ2
https://github.com/servo/servo/pull/18988 has merged a while ago in servo, but
since the sync service is down, I haven't been able to land the relevant patches
today.
This at least ensures that the build isn't busted when servo-vcs-sync goes back
up.
MozReview-Commit-ID: 9ohgwcnMc5T
There are four things that must be provided for every static atom, two of which
have a macro:
- the atom pointer declaration (no macro);
- the atom pointer definition (no macro);
- the atom char buffer (NS_STATIC_ATOM_BUFFER);
- the StaticAtomSetup struct (NS_STATIC_ATOM_SETUP).
This patch introduces new macros for the first two things: NS_STATIC_ATOM_DECL
and NS_STATIC_ATOM_DEFN, and changes the arguments of the existing two macros
to make them easier to use (e.g. all the '##' concatenation now happens within
the macros).
One consequence of the change is that all static atoms must be within a class,
so the patch adds a couple of classes where necessary (DefaultAtoms, TSAtoms).
The patch also adds a big comment explaining how the macros are used, and what
their expansion looks like. This makes it a lot easier to understand how static
atoms work. Correspondingly, the patch removes some small comments scattered
around the macro use points.
MozReview-Commit-ID: wpRyrEOTHE
--HG--
extra : rebase_source : 9f85d477b4d06c9a9e710c757de1f1476edb6efe
Because it's the type we use to set up static atoms at startup, not the static
atom itself.
The patch accordingly renames some parameters, variables, and NS_STATIC_ATOM,
for consistency.
MozReview-Commit-ID: 1a0KvhYNNw2
--HG--
extra : rebase_source : 5c66e5b2dfe053a368bf3584d957198aec4cce91
Check background attribute values for the same types (URL, image) in Stylo mode
as we do in Gecko mode.
In particular, this ignores the edge case of the empty attribute, which comes
through as a string value type, and leads Stylo to trigger a load of the page
itself as the background image (since the empty URL is interpreted as relative
to the page).
MozReview-Commit-ID: CUhq5nS8kVw
--HG--
extra : rebase_source : 8a04a3175cb1a873ee7e597ad881ae64720c01ef
This goes with a crashtest, as soon as I get a usable build.
MozReview-Commit-ID: LqmPWoJZ7AJ
--HG--
extra : rebase_source : a2f2e4b0b2f3cfa4c0f53bc5110d31f0fb86667f
This is kind of a band-aid because not all the media features chrome code uses
happen to be banned from content pages. But I'll change that soon.
Meanwhile this fixes scrollbars and such.
MozReview-Commit-ID: IVHljzpxc2z
--HG--
extra : rebase_source : 89329ad8b9991057e906b2d21a8120ed0c1e2b7d
We need to create a temporary ServoStyleContext with the animation value for
calculating the Cumulative change hints.
MozReview-Commit-ID: JzArnaGqVeV
--HG--
extra : rebase_source : 2947910e07f0aab6b385ca60cef927966d15bcf6
According to the spec, negative values are valid for inset(), so we should not
clamp it while computing and serializing negative calc values for inset().
MozReview-Commit-ID: DA21CaPO9w7
--HG--
extra : rebase_source : 235b4f144ebff1295853a559e867f4f904f0f061
nsComputedDOMStyle::BoxValuesToString() is a helper function for computing and
serializing box values. In the current implementation, BoxValuesToString
implicitly clamp negative calc values, which is pretty non-trivial.
In this patch, we expose an extra aClampNegativeCalc parameter for BoxValuesToString,
so the callers can explicitly set the clamping mode as needed.
MozReview-Commit-ID: 1UjLSqtqVzn
--HG--
extra : rebase_source : 9bdbb17fc8287fc5f9e505ffb8d5377917cac510
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
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
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
All our widgets support it with a constant true.
MozReview-Commit-ID: JMEItUsxYWq
--HG--
extra : rebase_source : a2661dce1ac191fdf098e631cd7878f0215643d5
This is unused right now, but will allow to change media feature visibility
without servo/ changes (along with https://github.com/servo/servo/pull/18774).
MozReview-Commit-ID: 75hahvROoJz
