Current Gecko composes all of effects in the composite order at once.
We can put each computed value into this AnimationValueMap every time composing
an effect.
MozReview-Commit-ID: EZdCYedva13
--HG--
extra : rebase_source : 0dc97045f2e5fd9088307fcd1588d9416907ba8e
The only one caller of GetServoAnimationRule is Gecko_GetAnimationRule.
There is no risk that pres context is destroyed in Gecko_GetAnimationRule.
MozReview-Commit-ID: 52pxbCiCNoJ
--HG--
extra : rebase_source : 8000e267d1d5706c709f807e11396dda3579c4dc
The relevant frame classes are:
SubDocumentFrame
ListControlFrame (only when used for (non-e10s?) comboboxes)
PluginFrame
ViewportFrame
MenuPopupFrame
The view is now created in the frame's Init() method, except for
ViewportFrame which has its view assigned by the frame constructor
via a SetView() call.
MozReview-Commit-ID: 4O7Hm1yqwIp
Views are used for PluginFrame which inherits nsFrame, not nsContainerFrame,
so it's more appropriate that these methods should live in nsIFrame/nsFrame.
MozReview-Commit-ID: 87EgCnkF5YT
Add one paramater to nsSVGDisplayableFrame::PaintSVG, so that we can pass
sync-decode flag from nsXXXXDisplayItem::Paint function to SVG paint call.
MozReview-Commit-ID: 6VZbxnFaoUj
--HG--
extra : rebase_source : c55e457e0d7a81b4a574d970924e0af6f7a7db48
According to bug 1345853 comment 5, tn said:
You probably want to return whatever was drawn there regardless of the
DrawResult. SVGMaskFrame has the same problem. Keep in mind that DrawResult is
only reporting on how drawing of any images went, not the drawing of anything
else. Also looking over the patches from bug 1258510 I see a couple places where
BAD_ARGS is returned if the transform matrix is singular. We would want to
return SUCCESS in that case I think, because we drew what we were instructed to
draw.
MozReview-Commit-ID: 5XcDuKQwXTJ
--HG--
extra : rebase_source : 5c558d469148e0cb3cfe9365aed1a4a65c572532
I did many change in many files in this patch. But the goal is pretty simple: To
pass the return value of nsSVGPatternFrame::PaintPattern back to the caller
(nsDisplaySVGGeometry). My suggestion is to review this patch right from
nsSVGPatternFrame.cpp.
I made two mistakes in bug 1258510
1. We should not return directly at [1]. RemoveStateBits at l418 will be skip.
2. nsSVGPatternFrame::PaintPattern should return both SourceSurface and draw
result, so that we can update UpdateDrawResult in display item.
All the other changes are to
1. make sure the return value of nsSVGPatternFrame::PaintPattern goes back to
nsDisplaySVGGeometry::Paint correctly.
2. Since the return value of nsSVGPatternFrame::PaintPattern change, we need
modify all existed callers.
I also filed bug 1346124 for handle the returning value of PaintMarkers.
[1] https://hg.mozilla.org/mozilla-central/file/c0700bedb4f7/layout/svg/nsSVGPatternFrame.cpp#l415
MozReview-Commit-ID: Iq9RPQ6Omz0
--HG--
extra : rebase_source : ca7a35bb9f5e27880d5dc62e03feb91b6ac3435d
This allows us to remove the #ifdef MOZ_ENABLE_WEBRENDER for the advanced layers
prefs from all.js. As additional advanced layers are turned on for webrender (or
non-webrender) they can be converted into override prefs without affecting the
call sites.
MozReview-Commit-ID: F9tMc23ow8A
--HG--
extra : rebase_source : 2244cb000711496ce5b7f1b50ef0314e1c312d94
Since -moz-element is moz only feature, the test case for -moz-element is
created under reftests/image-element folder.
MozReview-Commit-ID: G4V0G3cX7qr
--HG--
extra : rebase_source : f681d64fe4b9331a35fb082c7ed135f58c3f5a9d
It's ok to pass aRenderingContext to DrawableForElement, since DrawableForElement
only use aRenderingContext to create a similiar draw target. Replace
aRenderingContext by ctx make code more consistent since the draw call
bellow(nsLayoutUtils::DrawImage) use ctx.
MozReview-Commit-ID: 6n0nYfcFPui
--HG--
extra : rebase_source : 1374c8b5be9fe5351a5a126e39773c9493cf233d
If mask-mode is luminace, we will create a temporary context at [1]. It's
obvious we do not use this gfxContext at all in PaintGradient path. This patch is
trying to fix this problem by pass gfxContext, instead of RenderingContext,
directly to PaintGraident.
[1] https://hg.mozilla.org/mozilla-central/file/991f5724e58f/layout/painting/nsCSSRendering.cpp#l5811
MozReview-Commit-ID: LLmg4k6IEm3
--HG--
extra : rebase_source : ed42e3f5ddf1314300259c3f74d43aac8b4683de
According to bug 1345853 comment 5, tn said:
You probably want to return whatever was drawn there regardless of the
DrawResult. SVGMaskFrame has the same problem. Keep in mind that DrawResult is
only reporting on how drawing of any images went, not the drawing of anything
else. Also looking over the patches from bug 1258510 I see a couple places where
BAD_ARGS is returned if the transform matrix is singular. We would want to
return SUCCESS in that case I think, because we drew what we were instructed to
draw.
MozReview-Commit-ID: 5XcDuKQwXTJ
--HG--
extra : rebase_source : ba764df599844c9eb179736f61d6c7f6ee46c9fc
I did many change in many files in this patch. But the goal is pretty simple: To
pass the return value of nsSVGPatternFrame::PaintPattern back to the caller
(nsDisplaySVGGeometry). My suggestion is to review this patch right from
nsSVGPatternFrame.cpp.
I made two mistakes in bug 1258510
1. We should not return directly at [1]. RemoveStateBits at l418 will be skip.
2. nsSVGPatternFrame::PaintPattern should return both SourceSurface and draw
result, so that we can update UpdateDrawResult in display item.
All the other changes are to
1. make sure the return value of nsSVGPatternFrame::PaintPattern goes back to
nsDisplaySVGGeometry::Paint correctly.
2. Since the return value of nsSVGPatternFrame::PaintPattern change, we need
modify all existed callers.
I also filed bug 1346124 for handle the returning value of PaintMarkers.
[1] https://hg.mozilla.org/mozilla-central/file/c0700bedb4f7/layout/svg/nsSVGPatternFrame.cpp#l415
MozReview-Commit-ID: Iq9RPQ6Omz0
--HG--
extra : rebase_source : bc338b1a33f1dbf209706577b2455315dfb855e2
This ensures that we don't read incorrect values out of the gPropertyEnabled
array simply because we haven't gotten preference values from the parent process
yet.
MozReview-Commit-ID: 59AgN3ecXQl
The PR in question just added some pseudo-classes, and seems to have unearthed
some failures related to our lack of proper visited handling. Annotating.
MozReview-Commit-ID: GcbmWNDgwD0
sutagent is no longer built or usedr; devicemanagerSUT is completely
unused. After this change, devicemanagerADB is the only implementation of
devicemanager, and the --dmTrans and similar options have been removed
from test harnesses and mach commands.
I found this problem because I was debugging the failure of
layout/reftests/w3c-css/received/css-writing-modes-3/clearance-calculations-vrl-008.xht
with my patch for bug 1308876. It was failing because the red reference
box that was intended to be covered up was being mispositioned leftwards
by the width of the scrollbar, since we were not reflowing it when we
decided that the viewport did not need scrollbars. This patch fixes
that failure.
This led me to this bug, where
nsAbsoluteContainingBlock::FrameDependsOnContainer was incorrectly
testing conditions for when the values of 'top', 'right', 'bottom', and
'left' require reflow due to changes in the size of the containing
block.
The old code is incorrect in a number of cases, such as:
1. in RTL, with 'right: 100px', it will say that the frame does not
depend on its container's width since 'right' (offset-inline-start)
is a fixed offset and 'left' is 'auto'. However, since the
positioning is relative to the right edge, a change in container size
does require that the absolutely positioned element be repositioned
relative to the container's left edge.
2. In vertical-rl, again with 'right: 100px', it will make the same
mistake, since 'right' (now offset-block-start) is a fixed offset.
This is the case from the test I was debugging.
3. In vertical-rl with rtl direction and 'bottom: 100px', we will make
the same mistake because 'bottom' (inline-start) is fixed and 'top'
is 'auto', and we use 'bottom' rather than 'top'.
However, in cases (1) and (3) we actually avoid hitting the bug in these
simple-ish cases because ReflowInput::ShouldReflowAllKids() returns true
whenever IsIResize() is true, which means that
nsAbsoluteContainingBlock::Reflow doesn't even call
FrameDependsOnContainer. However, FrameDependsOnContainer should still
do the right thing because it's needed for
nsAbsoluteContainingBlock::MarkSizeDependentFramesDirty, which is only
used (from nsBlockFrame) when we reflow again for clearance or for
interruptible reflow. I haven't attempted to write a testcase for that
because it seems likely to require spending hours in the debugger trying
to trigger the right code.
This means that the only test that fails prior to the patch is
dynamic-offset-vrl-001.html, which exercises case (2), and also happens
to be the most similar to problem in clearance-calculations-vrl-008.xht.
This patch also makes the tests stricter so that we do optimize away
resizes in some cases where we're able to do so, such as
'left: 100px; right: auto' in RTL. (Or, rather, we would if it weren't
for the IsIResize() in ShouldReflowAllKids().)
MozReview-Commit-ID: 8xm1AHC21oh
--HG--
extra : transplant_source : %06%B4%40%EB%A9%C8M%F3%99%80%A9%DE%1F%1E%90%D3%F1%04W.
The calculated 'fr' value might change in the second round (after
applying min/max-size) even if it's zero in the first round.
MozReview-Commit-ID: 60moiyoWwuo
The "origSizes.isSome()" condition on the outer if-block was
a logical mistake. We should check it before re-assigning
mSizes though (this was the optimization originally intended).
MozReview-Commit-ID: AooUHYKG3jB
The <fill-rule> in the polygon() syntax is not handled because it doesn't
matter to shape-outside at all.
The reftests are numbered from 018 to avoid conflict with the w3c upstream
ones according to this list.
https://test.csswg.org/harness/results/css-shapes-1_dev/grouped/
Reftest 018 to 025 are under various writing-modes, 026 to 029 are testing
empty float area, 030 to 031 are testing polygon containing horizontal
lines.
MozReview-Commit-ID: FPUbMdZsvu6
Remove WritingMode parameter from LineRight() and LineLeft() in both
FloatInfo and ShapeInfo.
Bug 1316549 Part 3 added the parameter to compute the border radii under
writing-modes correctly. However, bug 1326407 Part 6 later made us cache
border radii, so the WritingMode parameter is no longer needed.
MozReview-Commit-ID: DFhm5d51OXJ
The idea is to be able to call the right function during style resolution time
without doing a linear walk via nsCSSAnonBoxes::IsNonInheritingAnonBox.
MozReview-Commit-ID: JKt33GggTjz
--HG--
extra : rebase_source : fcf477dcef8529c803bf97b1d3a16f8f4fcea39f
Really, there are only two cases we need to worry about. Either
IsSelectionCached(), and then our SelectionProperties has the data we want, or
not and then we have a non-null mSelCon which has the data we want.
Since we are now using cached selection state a lot more (instead of
initializing the editor whenever someone asks for selection state), we need to
actually update it more correctly when .value is set.
And since we now update the cached selection state for the case when .value has
been set (to point to the end of the text), we need to change
HTMLInputElement::HasCachedSelection to return false for that case. Otherwise
we will always do eager editor init on value set. We handle that by not doing
eager init if the cached selection is collapsed.
The web platform test changes test the "update on .value set" behavior. They
fail without this patch, pass with it.
MozReview-Commit-ID: DDU8U4MGb23
We have more tests failed in test_value_storage after introducing
Frames timing functions. I put it together with `animation` pattern because
part of the error messages of `frames` pattern are put in the `animation`
pattern.
MozReview-Commit-ID: KP5Y6HEH90D
--HG--
extra : rebase_source : df50def9736b813ee7428bb22b9cd191bcaa6ae9
Delete #include "mozilla/Logging.h" because it has been included.
Add FontFaceSet::Document() to get valid document for nsFontFaceLoader.
MozReview-Commit-ID: IAXM9UgvjOE
--HG--
extra : rebase_source : e5aa8aadea5e2f9f2e5d73cc718318cf97471d3f
This runnable is to delete object only, so using system group should be
fine.
MozReview-Commit-ID: 8uMxMO3yERG
--HG--
extra : rebase_source : 75ae4953d4c91fa0ab9a0c598a1989fa122f8f5a
