We create a clip region with the text length to make the decoration line
would be only drawn in the area. This allows the decoration line would
not be drawn multiple times when the text is being selected.
MozReview-Commit-ID: 4gjawk71eSu
--HG--
extra : rebase_source : 627fa77a2b6e17441d134255017762ebda92eaf6
Rendering at least aDirtyRect is more important than staying under
aPrerenderSize, so that's what we do.
MozReview-Commit-ID: 8Ze1biaNzqX
--HG--
extra : rebase_source : b04aedafa8432004a716f0cb4b4c5dc6c418dfda
The code previously used GetClippedBoundsWithRespectToASR() (changed
in bug 1298218), but this violated the requirements of nsDisplayList::
ComputeVisibilityForSublist().
MozReview-Commit-ID: F9UVMvVKLAp
--HG--
extra : rebase_source : ec188650070d4e8de1b19395c3ed6f31e7d0e04f
We allow an nsDisplayMask item to satisfy the requirement even it does not
itself have a clip, as long as its children have finite bounds with respect
to the ASR.
MozReview-Commit-ID: 8zKE0bguY38
--HG--
extra : rebase_source : 74baaea2647708d1cd024f9e6afd82508e95c74a
The test was asserting that a point on the boundary of an SVG path is inside
the path, but for a point that's right on the boundary, either answer
(inside or outside) is reasonable.
MozReview-Commit-ID: 8srcoPFmDq
--HG--
extra : rebase_source : 8870b0d92cc7c7ff0e52148197c46de99d597773
The last places that call this function have been removed in
https://hg.mozilla.org/mozilla-central/rev/0f7e0529ee3f,
and never been used since then.
MozReview-Commit-ID: FQtnwRHQ8cH
--HG--
extra : rebase_source : 3c40d0077c4b38771deed7055fbc5e22be8a071f
We need to get the offset across documents boundaries, since the scrollframe
might be inside a subdocument. In such cases we were previously computing
a (incorrect) zero offset for the scrollframe, which was throwing off the
margin for the sticky items inside the scrollframe.
MozReview-Commit-ID: AWeQ9ay2cmp
--HG--
extra : rebase_source : 7dd8eda26c482cc359042d79073740524efa792a
The only thing we use the PresContext for is the app units. I'd rather not
worry about keeping around a PresContext for the webrender display item
grouping.
There's no reason I can think of this wouldn't work, and try is totally green
without it.
MozReview-Commit-ID: K9QXbAOFu3A
--HG--
extra : rebase_source : 13eb1928d2b31f451610ca633d12cf912670e4e4
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
And unthrottle them on every 200ms just like we do for transform animations on
the compositor. To unthrottle the transform animations properly, we need to
update UpdateLastTransformSyncTime each time we compose the style for the
animations instead of updating it when we send the transform animation to the
compositor. That's because display item for transform is built even while we
are throttling the transform animations for some reasons, so if we updated the
last transform sync time there, the time will not match what it should be.
MozReview-Commit-ID: GwMzJqUlzd2
--HG--
extra : rebase_source : 09e379191970687a9f35aead871acf450c63813e
Minor note:
reftests should've turned off uploadEnabled in the first place.
reftests should have unified telemetry on. It's the future.
MozReview-Commit-ID: 9spzuUAXwwP
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
Bug 1393383 already added support for these kinds of display items (where the
border radii are not all the same) to the BuildWebRenderCommands function, but
for some reason CanBuildWebRenderCommands was left untouched and so we do
a fallback for these items when we can support them just fine.
MozReview-Commit-ID: GOAaQMfF2YQ
--HG--
extra : rebase_source : f5f7a87483347e97b5b95dd535c5497d355aebf3
These tests were failing because of some misoptimizations that GCC did.
clang is generating correct code here, and the tests correctly pass, so
we can mark them as such.
This extends the fix in bug 1373802 to account for extra levels of
display item nesting. If those extra intermediate display items don't
push any clips we still want to pick up the ClipAndScroll from the
enclosing ancestor that has it.
MozReview-Commit-ID: AmxRz4fBKnX
--HG--
extra : rebase_source : ae12a9f797ab201169ff199d0d42a29df51ee1cb
We already support cases where we have scrolling clips applied to fixed
items. However if we had to build nested clips inside those items, then
those nested clips would not properly inherit from the scrolling clips.
This patch addresses that case.
MozReview-Commit-ID: CWp1x0EsyaP
--HG--
extra : rebase_source : f8c80ace2da39edebaabd5339670a68038a18489
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
The reftest box-decoration-break-with-inset-box-shadow-1.html was affected
by both PR 1910 and PR 1918.
The reftest backface-visibility-2.html was affected by PR 1914.
MozReview-Commit-ID: JFwhmttGJjQ
--HG--
extra : rebase_source : 7e716a64aa0de2f862b9bea7c0d30131e92ba319
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
It was using the visible rect of the display item before, which can be larger
than the frame for various reasons. But the bounds we pass for the webrender
iframe item determines the iframe's position, so it needs to be informed by the
layout position of the frame, not by circumstances of the paint.
MozReview-Commit-ID: JSmFGLmAm0h
--HG--
extra : rebase_source : ba85778fe1fe509dd593afaac9bf7a4ff9952b49
I'm drive-by removing the comment about the frame tree state because I looked
into it, and the answer is: we properly restore it.
The gotcha is that we retain it too much, indeed, we retain it enough that it
can leak. See bug 1397239.
MozReview-Commit-ID: LP6bXkduEZ4
--HG--
extra : rebase_source : f7e18fc35e48b75c07fcc84b939614d379926828
This requires exposing the reftest chrome package to content, but that should be
OK, and this seems to work...
MozReview-Commit-ID: EWkwqTHW3dg
--HG--
extra : rebase_source : 12cabe4389375ac4c3abd0a9327baf268aab7c1a
Before this patch, we had been checking each scrollable ancestor is scrolled
out of its scrollable ancestor. So if the target animating frame is at the
bottom of its scrollable parent and if half of the scrollable parent is
scrolled out of its ancestor, the animating frame was considered as 'in-view'.
MozReview-Commit-ID: BDueuF3cT4I
--HG--
extra : rebase_source : de1dead6e67a44691887c8364be23734c3b1adef
Usage of sync was a mistake when porting from the previous std::ostream code.
MozReview-Commit-ID: HwbFVlZMu6t
--HG--
extra : rebase_source : 86d251a9b73013356e4cc9323d35121839fafba9
This edge case happens when:
- we have a display item A nested inside another display item B
- B has pushed an out-of-band clip, and
- A's clip chain doesn't connect directly to the end of B's clip chain
but instead connects somewhere farther up the clip chain
See comments in the patch for more details.
MozReview-Commit-ID: 4mCCaVUQuvH
--HG--
extra : rebase_source : 1601a8f0c586d618d395b4e20086b9ecd318945b
My original understanding of the API was flawed, and so while I had
position:sticky working in some cases it didn't work properly in a lot
of other cases. This patch corrects the usage of the API to match what
WR is expecting and fixes a lot of test cases.
MozReview-Commit-ID: AdMux19Fk9U
--HG--
extra : rebase_source : e7f970a710b2079501a91eeeac8c292b603210dc
Most of this change is just fiddling with function signatures so that they take
a LayerManager* instead of a Layer* (or in some cases, both). This allows
the WebRender codepaths to pass a WebRenderLayerManager* instead of having to
produce a Layer* which it doesn't have.
MozReview-Commit-ID: Fb0C8OUVDin
--HG--
extra : rebase_source : e4c3324cfa20c295db85d5c09df8d8d77865bb6a
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
This does 3 things that were all a bit too intermixed to split out cleanly:
1. Teaches TextDrawTarget to handle rectangular clips (while also completely
forbidding other ones). This is necessary to handle how gecko "overdraws"
decorations with clips to create the illusion of continuous lines when they're
actually made out of multiple lines, possibly from different display items
with different lines. Previously gecko *was* handing these clips to
TextDrawTarget to use these clips, but we were just ignoring them.
This is also necessary work to support partial glyphs natively (which apply
rectangular clips to glyphs). Also note that this currently causes a bug
in webrender if combined with zero-blur shadows, but it's not a regression
since we already mishandle clipped decorations. I will work on fixing this
upstream.
2. Changes the intermediate representation of lines from the old webrender
format to a rect-based one. This is in preperation for webrender adopting
that format in a future update.
3. Changes the way wavy lines are processed, correcting some errors in the
old wavy line bindings that lead to them being positioned incorrectly. Also
introduces a wavyLineThickness property that the will be required in a
future webrender update. Wavy lines are unlike any other line, so it's
ultimately desirable to distinguish them.
The net result of these changes is that a companion upstream change (webrender#1923)
will make decoration rendering nearly identical to gecko, and much nicer.
However the clipped shadows issue will need to be seperately resolved before
actually closing this issue.
MozReview-Commit-ID: 6O2wLA6bU3C
--HG--
extra : rebase_source : 17254c45145229b75f77f87f85874e66e6edd05e
Alex Gaynor
Kevin Chen
Mats Palmgren
Neerja Pancholi
fantasai
KuoE0
Ethan Lin
ANDREEA PAVEL
Emilio Cobos Álvarez
Xidorn Quan
Botond Ballo
Hiroyuki Ikezoe
Miko Mynttinen
Kartikaya Gupta
Sebastian Hengst
Ryan VanderMeulen
Jeff Muizelaar
Cameron McCormack
Csoregi Natalia
Matt Woodrow
Phil Ringnalda
David Anderson
Mike Hommey
Kyle Machulis
Margareta Eliza Balazs
Chris Peterson
Attila Craciun
Jonathan Kew
Chris H-C
Markus Stange
sotaro
Joel Maher
Nathan Froyd
Ray Lin
Boris Chiou
Daniel Holbert
Nicholas Nethercote
Makoto Kato
Morris Tseng
Boris Zbarsky
Henrik Skupin
Jesse Ruderman
Brad Werth
Alexis Beingessner