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
Currently, Selection::NotifySelectionListeners() moves focus before setting mCalledByJS to false. Therefore, if moving focus causes some calls of internal Selection methods, it may cause moving focus due to mCalledByJS being still true. So, mCalledByJS should be set to false before moving focus in NotifySelectionListeners().
MozReview-Commit-ID: F879bOmhZlv
--HG--
extra : rebase_source : 80790d24f1c78d9aeb20e5735e0c7c45111e69b3
The feature is controlled by pref layout.accessiblecaret.timeout_ms, and has been disabled in bug 1268410.
It's time to remove relevant code from the tree.
MozReview-Commit-ID: LLu8RiQcTpm
--HG--
extra : rebase_source : 906299afe9fbcb4bad2c74c83f19eb98b8815882
Since GetParentObject has a chance returning nullptr, we keep the original
code path as a fallback.
MozReview-Commit-ID: LCJefr1ZH6t
--HG--
extra : rebase_source : 16b791d9555e9d3fb6e00233868249cbd08d944f
cssPseudoElementBeforeProperty and cssPseudoElementAfterProperty are for
CSSPseudoElement.
MozReview-Commit-ID: 3WETv4QeC5
--HG--
extra : rebase_source : b7e902786ca9ebe7c92a573604e15d868c6067a7
There are two reftest
filter-region-01.html tests on filtered outer svg element. FF can not pass this
test without Part 2.
filter-region-02.html tests on filtered inner svg element, FF can pass this test
without Part 2. I add this in case we make a mistake in the future.
MozReview-Commit-ID: 1iwQWh0C7DH
--HG--
extra : rebase_source : 4770c99b1b81a593acdd4810fadc34376db93c13
extra : source : 6389fa0ca948dfc988778d2a3b808bb552dd60e3
inSearchLoop is referenced from nowhere, as a result, we don't need to get its timer event labeled.
MozReview-Commit-ID: 5fxg38WD9dQ
--HG--
extra : rebase_source : a72f150e15605e604e969c725ed4a23168bda1b4
Override OnScrollPositionChanged() in ScrollState because we want to update
carets during scrolling in subframes without APZ.
Due to the observation in bug 1273045 comment 8, we do not distinguish
PositionChangedResult::NotChanged and PositionChangedResult::Changed.
Instead, we always update caret even if its position is not changed.
To avoid excessive CaretStateChangedEvents are dispatched in
OnScrollPositionChanged(), we add IsScrollStarted to distinguish whether
OnScrollStart() is called or not.
MozReview-Commit-ID: KNi9Mct4dSk
--HG--
extra : rebase_source : 61d29fb0e1b6b91971217d3f45a791c456fa4f07
Part 2 is going to add a new hint which will use with RespectOldAppearance.
Hence this patch.
Remove #include "mozilla/WeakPtr.h" and "nsWeakReference.h" because they're
not used in the header.
MozReview-Commit-ID: KiNv0M0v8iO
--HG--
extra : rebase_source : 0969fc5accf11ac69bc97e3a51569b063172ffe3
The Gecko restyle manager does this synchronously, along with a content flush.
In my testing there's no need to do so, and Boris couldn't think off-hand of
why, except the fact that we have this mRebuildAllStyleData thing that takes
care of rebuilding the rule tree, which is quite sensitive.
Also, Boris made a good point about non-inheriting anon boxes, that could
technically change style. I've left a note about it too.
MozReview-Commit-ID: 2lvzhxugKB0
--HG--
extra : rebase_source : 38cf56811f73f5a9f0f6659e08d03e78d4c6dcb5
This allows us to test our media query stuff at least, and works around the fact
that we don't set mUsesViewportUnits.
This will get us better test coverage, at the expense of more expensive window
resizes and similar, temporarily.
MozReview-Commit-ID: 7lgELz86lmW
--HG--
extra : rebase_source : c6d62438b1d76d5adb9eec3a26ef47af1a84924c
This makes two changes:
* adds "on the line" to clarify what last means
* adds "when combining <failure-type> from the manifest include and the
test line" to clarify that the parenthetical only applies to combining
at different levels, and not within a line
DONTBUILD
--HG--
extra : rebase_source : 4e45753f11b20313ed010ec8d01e0403b89591fd
extra : amend_source : c1f4acb341f0cb2f713080e73c686a5e67aed521
