Most of this patch is just mechanical changes, but note that this patch
now makes the mFlags in scrollbar-container nsDisplayOwnLayer instances
have one of the direction bits set. As a result, this requires changing
the implementation of nsDisplayOwnLayer::IsScrollThumbLayer().
MozReview-Commit-ID: 2BLdbpz5Sa8
--HG--
extra : rebase_source : 27e7d90ce60c7f702fe77d8a3a0f7e3ae3e4a4ff
The property in question is the offset from the content process to the
chrome process, but it gets called various things for historical
reasons. Let's be consistent and just call it the chrome offset
everywhere.
Also, in some places this was needlessly getting turned into a
nsIntPoint via ToUnknownPoint(), only to be turned back into a
LayoutDeviceIntPoint at all the use sites. So this patch also updates
some function signatures to avoid the needless conversion.
No functional changes.
MozReview-Commit-ID: AuhEUfa64Uj
--HG--
extra : rebase_source : 20e1895fefd944f98307a8437f977252ee2c3185
It's good to save some copy constructor calls.
MozReview-Commit-ID: 6TveqwkOvc0
--HG--
extra : rebase_source : 02e678f985c074f6c972cf8478e233aa5e4607db
In the current implementation, when hyphens property is set to auto, we do some
math to determine the index of text fragment, so we can check whether a character
is an explicit hyphen. However, the math calculation is not reliable, and it is
not easy to calculate the fragment index when there are more than one fragments
in a gfxTextRun, e.g., a paragraph which consists multiple inline elements.
In this patch, we simply use GetOriginalOffset() to get the position relative
to the current text fragment, and scan/detect explicit hyphens correctly.
MozReview-Commit-ID: JIg3tdpViRH
--HG--
extra : rebase_source : a6ac03914badd2f2dcd238186a6653e8660bc116
Many members of nsFrameSelection are uninitialized, which could cause some
potential issues. In this patch, we use per-member defaults for nsFrameSelection,
and make sure we initialize all the members properly.
MozReview-Commit-ID: H9MMlSZoinh
--HG--
extra : rebase_source : c68ac4f61a687fd981363efa924fdbb2e0804b10
In this patch, we move the member assignments in nsFrameSelection's constructor
to nsFrameSelection's class definition. This is a pre-patch for switching
nsFrameSelection to use per-member defaults. With this patch, all the uninitialized
members can be tracked easily.
MozReview-Commit-ID: 1HhTDlV73QN
--HG--
extra : rebase_source : f97f7a46ba70e1f36f4812591d73b64061cf0c9e
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
--HG--
extra : rebase_source : 6d45b0fc40a90ca141a267ec7f152a8bd6d33932
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
--HG--
extra : rebase_source : 8a4a6bf912f88b35f2ed86f9a84ddb74e69bde38
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
--HG--
extra : rebase_source : a9cc5ecfc7c5baeab2f6e08cd2ee2c2a7756e20c
This patch amends an existing workaround, but as the NOTE there says,
we should have pulled up those floats and reflowed them somewhere
(and pushed them again potentially, and then we wouldn't be COMPLETE).
It's unclear to me where that pull-up is supposed to happen though.
MozReview-Commit-ID: ES2rb1l7jyi
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
--HG--
extra : rebase_source : d610dd7f4c3aa48fbcae0d9bed4736b89cf7b659
Skip files under intl/icu/ because they're imported from third party.
DONTBUILD because this is a whitespace-only change.
MozReview-Commit-ID: GSd6oeFSTO7
--HG--
extra : rebase_source : 38c20bf6099c18b2fcb4c324d470b279addf8891
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
--HG--
extra : rebase_source : 2569f2ebaf72a1a4784cf58a76f14382811412e7
nsBlockFrame::DoRemoveFrame destroys the continuations in first-to-last
order. Unfortunatley, this means that frames for anon/generated content
that were pushed to a later continuation may already be unbound by
the time we destroy its frame. This patch fixes that by collecting
anon/generated content from all the continuations, rather than from
each continuation separately.
MozReview-Commit-ID: LPBSoqjfjnA
The core of this change is in gfxContext.*:
- change gfxContext::CurrentMatrix() and gfxContext::SetMatrix() to
return and take a Matrix respectively, instead of converting to
and from a gfxMatrix (which uses doubles). These functions therefore
will now match the native representation of the transform in gfxContext.
- add two new functions CurrentMatrixDouble() and SetMatrixDouble() that
do what the old CurrentMatrix() and SetMatrix() used to do, i.e.
convert between the float matrix and the double matrix.
The rest of the change is just updating the call sites to avoid round-
tripping between floats and doubles where possible. Call sites that are
hard to fix are migrated to the new XXXDouble functions which preserves
the existing behaviour.
MozReview-Commit-ID: 5sbBpLUus3U
