Borders are rarely a single app unit tall and this code is
from long long ago (bug 41262)
--HG--
extra : rebase_source : 7e2d5a70649ddfb7ab6da8ea26efd6da85ba3f1f
Whenever the inverse of a 3D projective transform is applied to a point, only use the result if it has a positive w-coordinate.
When transforming by a matrix that we know should be 2D, assert to that effect.
Transformations of rectangles (as opposed to points) remain to be audited.
--HG--
extra : source : a183e31473fcca0d20e2331fdbd93b8cc0cee824
forms.css sets overflow: -moz-hidden-unscrollable on all select elements.
ApplyOverflowClipping in nsFrame.cpp applies overflow clips that are not managed by scroll frames.
nsCSSFrameConstructor::ConstructSelectFrame creates an nsListControlFrame for listbox select elements.
nsListControlFrame is an nsHTMLScrollFrame.
As a result, the clip as applied twice - once by the nsHTMLScrollFrame, and then again by ApplyOverflowClipping.
Adding an exception for nsListControlFrame to ShouldApplyOverflowClipping gets rid of the double clip.
--HG--
extra : amend_source : e6c8e548e31b3f1740f2c32a3aaff560f72d3427
This makes those caret display items not share a layer with any other display items, and uses a different async scroll frame clip for that layer.
--HG--
extra : rebase_source : f01cd0343ea3e672b1d696a4e4e8924d070cc23d
extra : histedit_source : 14cefb8c1c9834d02a095e52e463add8a56a8625
Store the content box clip on mAncestorClip, and store a different clip for the caret on mAncestorClipForCaret.
In a future patch, those clips will be selectively applied to the right layers.
--HG--
extra : rebase_source : e87e63a7ba5e963b7e3b22b5d93dc8c473a6a905
extra : histedit_source : b0e2193cf73222e51ed641e84ccaea8001e47324
Instead of looking at the caret's rect and determining whether we should clip it
to the real content box clip or not at all, we just always clip it, but to a
slightly bigger rect. In the cases that the caret was completely visible before,
it'll still be completely visible with this change. However, in the cases that we
did decide to clip before this patch, the result can be slightly different now:
Before this patch, whenever the caret was partially clipped, it was partially
clipped to the true content clip rect, but with this patch, the caret can be
partially clipped to the slightly larger clip rect.
--HG--
extra : rebase_source : 645afe6474f28a6e10abfeb63172fb480116a6f7
extra : histedit_source : 110328d864d45660335121c8cf7a5994dfea81b8
I confirmed that animate-preserve3d-child.html still fails without the
original patch in the bug.
--HG--
extra : transplant_source : %2Bqq%E3%28f%BC%CF%E0%02%205.%14V%ABX%F1%87%1B
libvpx dropped vpx_mem_set_functions,
only use it if an external libvpx
is used and still has it.
update update.py
add vpx_dsp_rtcd.h
rebase disable_pthread_on_mingw.patch
add vp9_filter_restore_aligment.patch
drop msvc2015.patch
This conversion was done with the script:
find . -name '*.cpp' -o -name '*.h' -o -name '*.mm' -o -name '*.idl' | \
egrep -v 'cairo-win32-refptr.h|RefPtr.h|TestRefPtr.cpp' | \
xargs sed -i -e 's/mozilla::TemporaryRef</already_AddRefed</g' \
-e 's/TemporaryRef</already_AddRefed</g'
Manual fixups were performed in the following instances:
- We handled mfbt/RefPtr.h manually so as to not convert TemporaryRef itself
into already_AddRefed.
- The following files had explicit Move() calls added to make up for the lack
of a copy constructor on already_AddRefed:
dom/base/ImageEncoder.cpp
dom/media/MediaTaskQueue.{h,cpp}
dom/media/webaudio/PannerNode.cpp
- A redundant overload for MediaTaskQueue::Dispatch was deleted.
- A few manual fixups were required in mfbt/tests/TestRefPtr.cpp.
- Comments, using declarations, and forward declarations relating to
TemporaryRef in dom/canvas/ and gfx/layers/ were changed to refer to
already_AddRefed.
frame->Preserves3D() is whether the frame's parent has transform-style:
preserve-3d, which means that the frame is part of the same 3-D scene as
its parent. frame->Preserves3DChildren() is whether the frame itself
has transform-style: preserve-3d, which means that the frame is part of
the same 3-D scene as its children.
Neither of these are valid cases for doing off-main-thread (OMT)
animation because all of the layers in a preserve-3d scene are currently
siblings of each other, rather than preserving ancestor/descendant
relationships. This means that it's not valid to animate transform of
the parent on the compositor because the compositor animation won't
update any of its children that have layers. Likewise, it's not valid
to animate transform of the child on the compositor because the code
that sends transform information to the compositor doesn't handle the
accumulation of transforms needed to get the "right" transform for the
child (i.e., with the transforms of its ancestors up to the top of the
3-D scene merged in).
This means that we do OMT animation for slightly fewer cases with the
patch than we did without the patch. This means it's pretty low risk in
terms of correctness, although there's a chance it might regress
performance on one of the (somewhat limited) set of cases where the
optimization was valid. (Bug 779598 covers doing OMT animation for
preserve-3d cases, and depends on the work ongoing in bug 1097464.)
The animate-preserve3d-parent.html reftest doesn't fail without the
patch, since something seems to invalidate in the test; it was testing
the testcase that showed correct behavior when the mouse was moving, so
this isn't incredibly surprising (although that invalidation from mouse
movement is itself worth debugging). The animate-preserve3d-child.html
test does fail without the patch, though.
(With an initial transform of none instead of the 30deg transform, both
tests also show an invalidation bug without the patch.)
The patch works by not handling transform:none specially at all, which
will lead to a scale of 1 (instead of the current 0).
This is the patch that actually fixes the original problem reported in
bug 1122526. This patch also fixes bug 1165196.