Turns out that there's been a bug in the event regions code since it was
first written, where touch-action:manipulation is not properly expressed
in the event region structs. It's sort of a design bug that we can't fix
without adding another region. However, in bug 1389149 I accidentally
changed the behaviour of some of these cases because I wasn't aware of
this bug. This patch repairs the code so that it behaves the same as it
used to prior to bug 1389149, and documents the buggy scenario.
MozReview-Commit-ID: 9XhkH6ypZHi
Sometimes, when adjusting the frame construction procedure, the relationship
between parent and child would be unexpected. So, adding the parent info
into that allows us to notice the expected result.
MozReview-Commit-ID: 8DWOXing463
Create hit-test info items (if enabled) for each frame that is not
invisible to hit-testing. This is not optimized at all yet, so it
creates a lot of display items if enabled.
MozReview-Commit-ID: LFqoaZ9e99F
This introduces a enum bitset type that encapsulates some of the
interesting properties that frames have that make it interesting for
hit-testing in the compositor. This type is designed so it can be sent
directly to webrender and gotten back in the hit-test.
MozReview-Commit-ID: GCxV7ZaoJd1
Find out where we use MayHaveTransformAnimation in EffectSet
and change them to MayHaveTransformAnimation in nsIFrame.
MozReview-Commit-ID: GhkztK8JtNa
There are two places where I have to cache the status of MayHaveOpacityAnimation
and MayHaveTransformAnimation. First place is in |nsIFrame:init()| where an
element is associated with a frame. Second place is in
|KeyframeEffectReadOnly::UpdateEffectSet()| where the script can add animations
on element.
btw I keep the original two flags of MayHaveOpacityAnimation and
MayHaveTransformAnimation in EffectSet because there is no guarantee that
an element has been associated with a frame when we call to |UpdateEffectSet()|.
But we still want to keep the benefits that we can quickly look up
MayHaveOpacityAnimation or MayHaveTransformAnimation. So I keep them in
EffectSet and transfer the status into nsIFrame when we bind an element
to a frame in nsIFrame:Init().
MozReview-Commit-ID: JDwyAQQTKA7
The pref "browser.ignoreNativeFrameTextSelection" was used only by B2G, and
currently not enabled elsewhere, so this code is dead now. Also, this
functionality is obsoleted by AccessibleCaret.
MozReview-Commit-ID: 2kHYXLueFH5
I believe this is a typo. This fix will not affect the existing frame dump result
because the input parameter, i.e., aTo, has been initialized to empty string by
the caller before calling. So, the first line of nsIFrame::ListGeneric can be
written as:
a) aTo =+ aPrefix;
b) aTo += aPrefix;
c) aTo = aPrefix;
and all three results are the same at present.
In this patch, we fix the typo by choosing (b) to make it align the rest parts
of nsIFrame::ListGeneric.
MozReview-Commit-ID: CHJDyVSJj5W
