This makes these lines shorter, and brings us into alignment with the Mozilla Coding Style Guide. See mozilla.dev.platform post "Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used" for more info.
nsLayoutUtils::CalculateCompositionSizeForFrame() is not affected by the
document resolution when called for the root content document's root
scroll frame. When determining the root composition bounds in order to
calculate a displayport base, if the frame used is the RCD-RSF we must
be sure to scale the bounds ourselves by the document resolution.
MozReview-Commit-ID: ATctmEYvWIJ
--HG--
extra : rebase_source : ba96e7ecc2cefdbeacb08fbd3f5817819dd933c8
In my original design, I treat eTouchCancel to be like eTouchEnd for
ending a caret dragging procedure.
However when pointer events is enabled, it sents an eTouchCancel event
after the eTouchStart event whose primary usage is to be converted to
pointer events, which then cancels the normal caret dragging procedure.
Moreover, when pointer events is disabled, we don't get eTouchCancel
during a normal caret dragging scenario, so we don't really need to
handle eTouchCancel anyway.
MozReview-Commit-ID: GKju2Tp0q3Q
--HG--
extra : rebase_source : 31da189fc5543c7df0d748df004fc67c87f4da7f
This patch is generatedy by applying clang-format on
AccessibleCaretEventHub.cpp.
MozReview-Commit-ID: 10qPJ47CVMH
--HG--
extra : rebase_source : ff39be696ef4cd93ffbe0b9e7c95920aa03a6893
When enabling "dom.w3c_pointer_events.enabled", we might get a
eTouchCancel event without any touch data. That is, aEvent->touches is
an empty array. We need to make sure it's non-empty before accessing
aEvent->touches[0].
MozReview-Commit-ID: BQUsrJjHHEl
--HG--
extra : rebase_source : d5f435792ecc0cac79937121fa03ce6f22c59582
I think we're going to have a fair number of things like this, so I'd rather
put them all in one place, rather that defining them in the header for the first
consumer that uses the type.
reftest is disabled on windows due to localized try readback errors that can't be reproduced.
MozReview-Commit-ID: 379PZsRE5d6
--HG--
extra : rebase_source : b990572c0f33860998eb5485824e417387d3e204
Currently, CommonAnimationManager::GetAnimationCollection returns early when
the referenced list of animation collections is empty. So, for example, if
we try to get the collection of CSS animations on an element on a page with no
CSS animations, we will quickly return null without possibly expensive property
lookup. However, if there is just one CSS animation on the page, we will do the
property lookup for every element in the page where this method is called.
In this bug, we would like to remove the linked list of animation collections
since this is now the only place where it is used. So, in place if this
optimization, we introduce quite a different one based on the changes from bug
1226091 which makes MayHaveAnimations() apply to animations on the element
itself as well as pseudo elements. Using this, we can return early for any
element that has never had any kind of animation on it. The page may have
dozens of other animations but we will still return early. However, if the
element has ever had any kind of animation on it, we will not return early. It
is expected that this optimization is at least as good as the one it replaces.
In this bug we will trim off unnecessary functionality from the animation
managers and make AnimationCollection into an independent data type
so in this patch we separate it into its own file.
It is also generally easier to navigate the source code and eliminate
cyclic dependencies between header files when there is a rough
correspondance between class names and file names (e.g. rather than having
#include "AnimationCommon.h" // For mozilla::AnimationCollection).
This patch also makes a few simplifications to include dependencies since
they're a bit of a mess (making it hard to move code around). The changes to
IncrementalClearCOMRuleArray.cpp are due to the changes to the unified build
introduced by adding AnimationCollection.cpp exposing a missing include from
that file.
This was added in bug 780692 to work around assertions that arose due to the
inconsistent state introduced by mini-flushes. However, that workaround
no longer seems necessary. In particular, the crashtest for bug 813372 no
longer reports failed assertions when we remove this method and nor do any
other tests.
I'm not sure exactly what changed about how we do mini-flushes but I suspect
it was bug 960465 or one of the related follow-ups.
This patch removes a loop for the new temporary animation collection in
CheckAnimationRule. The old collection is passed to CSSAnimationBuilder,
and CSSAnimationBuilder removes each animation which matches to new animation
name in it.
:birtles took care of storing animations in AnimationCollection in reverse order.
Thanks so much!
MozReview-Commit-ID: KmlnjFptKdv
This removes a rule that was incorrectly added in the tests in patch 3,
which dholbert pointed out in a review comment (comment 18) made after
granting review (and only 3 minutes before I pushed the patches), which
I didn't see before pushing them.
I had incorrectly copied that rule from the
min-intrinsic-with-percents-across-elements.html test, which I based
these on.
MozReview-Commit-ID: IARSYkKkIRx
This reverts some of the changes made in bug 823483 patch 3 because it
turns out we don't want all of that behavior change.
MozReview-Commit-ID: Lbpi762qsbM
In nsDisplayListBuilder keep track of the total area of frames which
have been made animated geometry roots due to having animated offset or
margin properties. This is in order to reduce the total area of created
layers. Once the area has reached a certain limit do not allow any more
frames to be AGRs for this reason.
Currently this only applies to AGRs created due to frames having
animated offset or margin properties. This is because we believe this is
a major source of over-layerisation and too high memory usage. This
could easily be extended to include the creation of AGRs due to other
reasons too.
Note that this technically limits the area of AGR frames, not the area
of layers, though it will have a fairly direct impact.
MozReview-Commit-ID: BvgRrC8KMIp
--HG--
extra : transplant_source : %F3rp%193%1A%E4i%8B%E8%24%B1%FE%81%C2U%F8%3A%AEQ
Bug 1241917 made it so that a subframe's displayport base is restricted
to the root composition bounds (in addition to its previous
restrictions). This involved an expensive coordinate transformation
causing a scrolling performance regression.
This avoids restricting the displayport base to the root composition
bounds unless the frame has a display port, avoiding the expensive
computation unless necessary.
MozReview-Commit-ID: FVacUscAfu2
--HG--
extra : transplant_source : %F9%E9%19%06/%9C%EA%8C%D1%D5%BD%ED%26C%97y%15%92%7E%CB
After calling FlushLayout(), PresShell::Destroy() might be called and we
should consider PresShell and other resources will be no longer valid.
Before this patch, AccessibleCaretManager and AccessibleCaret(s) are
deallocated in PresShell::Destroy(). However FlushLayout() are all
invoked in AccessibleCaretManager, we need to keep manager alive to
clean up after PresShell::Destroy().
This patch makes AccessibleCaretManager live after PresShell::Destroy(),
and use IsTerminated() to check whether PreShell is vaild after each
FlushLayout() calls.
Note that event though AccessibleCaretEventHub will be unref in
PresShell::Destroy(), all the callers to AccessibleCaretEventHub's
public methods already add a ref to AccessibleCaretEventHub. So we don't
need to worry about AccessibleCaretEventHub and AccessibleCaretManager
die immediately after PresShell::Destroy().
MozReview-Commit-ID: DDpXZ7v3zyo
--HG--
extra : rebase_source : 2698f0313e394b64ff8caacf21493c874510a7ce
Fennec enables sCaretsExtendedVisibility which uses
Appearance::NormalNotShown instead of Appearance::None to keep actionbar
shown during scrolling. This breaks selection mode update when the
positions of the carets are not changed after scrolling.
To fix this, we need to implement appearance recovering for selection
mode scrolling like we did for cursor mode in bug 1212732, and make
UpdateCaretsForSelectionMode() respects UpdateCaretsHint.
MozReview-Commit-ID: LkfUIGKHL0h
--HG--
extra : rebase_source : 2e68786e09046967f7c6af16fa6b393f133dc12c
Pings are sent in the implementations of the nsISelectionController methods
ScrollLine, ScrollPage, ScrollCharacter, and CompleteScroll. It is assumed
that these methods are triggered by keyboard input.
A small number of false positives can occur if these methods are called
in response to something other than keyboard input; this is considered
acceptable.
--HG--
extra : commitid : JDXW8ptuXkF
extra : rebase_source : c45fe2b16484ad370edb852d8eafbc76ca7d0bac
extra : amend_source : b4af21228768221211a42c11a2ff306a6f2bb402
extra : histedit_source : 7cdc4b4df3579682fad194ddfc04c7a5d02c0d3e
Be warned. Do not attemp to change the .js "test" source code in ./js
They are meant to check
- the outdated 0666 octal constant is still parsed correctly,
- the outdated 0666 octal constant raises syntax error flag
in strict mode, etc.
So leave them alone.
Add helper function nsIFrame::In3DContextAndBackfaceIsHidden() which
checks both if a frame is backface-hidden and whether it is within a
3D-transform context.
In FrameLayerBuilder, check this function rather than BackfaceIsHidden()
to determine whether a frame needs a backface-hidden layer. This will
avoid creating unnecessary extra layers for non-3d-transformed items
which for some reason have backface-hidden set.
I confirmed locally that this patch does fix the assertion in the
crashtest.
MozReview-Commit-ID: L1TIAZZ1aNu
--HG--
extra : transplant_source : %FE_N%7D%AE%11%0D%92B%93%F6%3D%CFyY%3D5%7EFt
I confirmed locally that, without the following patch, the crashtest
harness does detect the single assertion.
MozReview-Commit-ID: FRkCdxSSa7V
--HG--
extra : transplant_source : xF%BC%7E%03%B3%1Bp%EF%07%D9%28%F6C%B5s%C7%C2%15%C1
Also I removed the 'explicit' keywords from the constructor since they have no
argument so nothing can be implicited converted to them.
MozReview-Commit-ID: GrFcqO0Uf1o
--HG--
extra : rebase_source : 5994787b7feccf409db1faf6359676b5170ea203
extra : source : a27cd3e26cc146006db501efb86b54b097f28b57
In order to convert CSSPseudoElementType into its underlying type easier,
we define CSSPseudoElementTypeBase. However, keep using uint8_t directly for
forward declarations.
Using explicit iteration at measurement sites is much simpler and nicer than
using callbacks.
--HG--
extra : rebase_source : 8b3f7aa702743b665383766b66a866a2c3d17240
Also I removed the 'explicit' keywords from the constructor since they have no
argument so nothing can be implicited converted to them.
MozReview-Commit-ID: GrFcqO0Uf1o
--HG--
extra : rebase_source : c4747c5e3ea09ddfc08bfc1b0c8e4bcedb1d75ce
extra : amend_source : 6289aaff79b22956b72956734e4d99bdd3b7977d
After calling FlushLayout(), PresShell::Destroy() might be called and we
should consider PresShell and other resources will be no longer valid.
Before this patch, AccessibleCaretManager and AccessibleCaret(s) are
deallocated in PresShell::Destroy(). However FlushLayout() are all
invoked in AccessibleCaretManager, we need to keep manager alive to
clean up after PresShell::Destroy().
This patch makes AccessibleCaretManager live after PresShell::Destroy(),
and use IsTerminated() to check whether PreShell is vaild after each
FlushLayout() calls.
Note that event though AccessibleCaretEventHub will be unref in
PresShell::Destroy(), all the callers to AccessibleCaretEventHub's
public methods already add a ref to AccessibleCaretEventHub. So we don't
need to worry about AccessibleCaretEventHub and AccessibleCaretManager
die immediately after PresShell::Destroy().
MozReview-Commit-ID: DDpXZ7v3zyo
--HG--
extra : rebase_source : 280e2512fb9f28d933f5b8d65a9f303ac81c58e5
extra : source : 10e71da98b144fbf42aaa81a1056910a3766a6cb
Fennec enables sCaretsExtendedVisibility which uses
Appearance::NormalNotShown instead of Appearance::None to keep actionbar
shown during scrolling. This breaks selection mode update when the
positions of the carets are not changed after scrolling.
To fix this, we need to implement appearance recovering for selection
mode scrolling like we did for cursor mode in bug 1212732, and make
UpdateCaretsForSelectionMode() respects UpdateCaretsHint.
MozReview-Commit-ID: LkfUIGKHL0h
--HG--
extra : rebase_source : 0ef8d28ce55c3ddd29ea32ee6888ee7fe14c34ad
extra : source : bc3e37b63defca87d0de165fe167ef7f8a7db651
- Generate and pass sequential frame indexes into the ovr_GetTrackingState call and the corresponding call to ovr_SubmitFrame
MozReview-Commit-ID: 5tJl5YJt7Eo
--HG--
extra : rebase_source : 5dbb35ea1451a9f378e28d81a8704b63b1b72b4d
In ActiveLayerTracker check if the value of a property has actually
changed, rather than being set to its existing value, before treating
the property as animated. This will help avoid over-layerization of some
frames.
On Fennec, it's possible that after automatically zooming an editable
input, the mImaginaryCaretRect for the caret remains the same. Only the
zoom level is changed. Therefore, the zoom level should also be
considered to determine whether the position is changed or not so that
the caret can get updated.
MozReview-Commit-ID: CrictS4S0Yl
--HG--
extra : rebase_source : f26f89cb72a9ae8a55104054121486a67e841513
It's not obvious that it does this (unless you read the comment or the code), and we don't gain much by doing it.
Also we need to split it up for the next patch in this bug.
- The VR specific render path in ContainerLayerComposite does not
handle nsBackdropFrame correctly, resulting in a alternate frame
strobing effect in the Oculus Headset. As VR content is composed
of a Canvas element that is scaled to the extents of the surface,
the backdrop would otherwise not have an effect for VR content,
which means we can simply suppress the backdrop.
MozReview-Commit-ID: 3bCTOApiH8E
--HG--
extra : rebase_source : 015e15dee2ac3235e1e571642d3988b66b97dfd1
CLOSED TREE
Backed out changeset dbadb8fe5803 (bug 1216001)
Backed out changeset a30593ebd58e (bug 1216001)
Backed out changeset c1646ffa71b4 (bug 1216001)
There is an ImportError on Android, as well as a log related
regression from the structured log patch once that is fixed.
MozReview-Commit-ID: KxSEotr38qO
--HG--
extra : rebase_source : 15d8421aab813d9e0dbf6d00611f921aaa779a49
To retain backward compatibility, <details> tags should not collapse its
children when dom.details_element.enabled = false.
--HG--
extra : rebase_source : 6b47e64672720ffecd23f670c31de1c7d92bee8c
test_value_storage.html needs floating point numbers to round trip through css
parsing and serialization, but floating point isn't exact so we should be
careful what numbers we test. It turns out the value 0.9 the test was using is
close to the border between 229 and 230 when converted to an 8 bit int, but 0.8
is safer so change to that since the test doesn't depend on the value. Note
that this does not fix the issue that numbers don't always round trip, but only
wall papers over it by changing the test.
Structured logs bring many benefits. We can stop parsing the logs for magic strings, we
can modify the format without breaking things, and we can stream results into systems like
ActiveData. The structured logs originate primarily in reftest.js. StructuredLog.jsm is
used to generate the JSON-based log stream. Finally OutputHandler in the python harness
reads structured output from stdout, and formats it into human readable form.
MozReview-Commit-ID: G3ZLkMRl6p7
--HG--
extra : commitid : J3ui9XYWR3Q
extra : rebase_source : 77ed0ba842cc8e557141fb3494212b06868c728a
extra : amend_source : 735d48225a2e627e0fe45fc11b50b6c49a885a4b
extra : source : d1779fe421c3c7cd8e3d191816776390dc104f37
This is a regression by "Bug 1121468 - Go to NoActionState after
receiving release on LongTapState."
When receiving a scroll event in LongTapState, i.e. apz starts, we
should call OnScrollStart() and move to the ScrollState.
--HG--
extra : commitid : GsQNnTtqhzh
extra : rebase_source : 0a6ad44a4bf97ed15b374094929df5409deeba41
This means that we won't associate animations with additional frames.
In this case, this fixes associating off-main-thread animations with a
table outer frame, when they should have been associated only with the
table frame.
Locally, the test fails without the patch (with opacity in the test
being 0.36 instead of the expected 0.6), and passes with the patch.
(Opacity 0.36 gives a color of rgb(163,163,255), whereas 0.6 gives
rgb(102,102,255).)
--HG--
extra : commitid : 7wtkIDLDHBF
Without this patch, patch 2 will cause assertions since
nsFrame::DestroyFrom calls nsFrame::HasCSSAnimations (at a time when the
child frame has been destroyed), which calls into the code modified in
patch 2 to call GetStyleFrame.
--HG--
extra : commitid : EkhtcNIf7ye
