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.
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
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
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.
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
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.
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.
CLOSED TREE
Backed out changeset dbadb8fe5803 (bug 1216001)
Backed out changeset a30593ebd58e (bug 1216001)
Backed out changeset c1646ffa71b4 (bug 1216001)
To retain backward compatibility, <details> tags should not collapse its
children when dom.details_element.enabled = false.
--HG--
extra : rebase_source : 6b47e64672720ffecd23f670c31de1c7d92bee8c
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
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
When double-clicking on a default anonymous <summary> element, the first
eMouseClick will make the summary element being removed from the
document. This generates an assert in
PresShell::HandleEventWithTarget().
To prevent this assert, ensure the mouseContent is in document before
dispatching the eMouseDoubleClick event.
Since GetCrossShadowCurrentDoc() was deprecated, replace it with
GetComposedDoc().
--HG--
extra : commitid : K9pCdof8z3f
extra : rebase_source : 3adfdb9938de30fd0ca365168c33dcdcef8ca285
This restores the quirky behavior for text inputs, which was removed by
patch 2, but only halfway (for width but not max-width), which matches
Chromium and Edge.
--HG--
extra : commitid : 7uk3XdYc1LC
This just reorders the if-else chain to change which conditions are
tested first. Prior to patch 1, the order didn't matter, but with patch
1, the order does matter, and the order that we happened to have was the
opposite of the one that matches Chromium and Edge.
--HG--
extra : commitid : 6sFft3gnM2g
This reduces the set of elements to which this quirky behavior applies.
This matches the behavior of Chromium and Edge.
--HG--
extra : commitid : 9qz7ODJhNzS
This (modulo changes in later patches) matches the behavior of Chromium
and Edge. It increases the set of elements to which this quirky
behavior applies.
--HG--
extra : commitid : 4nWEgnUB0rt
Per request in bug 1240917 comment 15, we decided not to show caret when
single press on an empty input. This effectively reverts the work in Bug
1230582.
--HG--
extra : commitid : IjKGpqAR6zP
extra : rebase_source : d476618b4f419cf2d96bb33264cfd8ccb6e3fa61
Nothing() represents linear function, i.e. skip calculation.
ParseEasing is changed to return a Maybe<ComputedTimingFunction>,
if timing function is linear function, ParseEasing returns Nothing().
This is a patch for compositor side to represent linear function as null_t/Nothing().
Also the first argument of ToTimingFunction changes to a Maybe<ComputedTimingFunction>.
As a result of this change we can also use ToTimingFunction for animation
effect's timing function.
This adds the value -moz-window-dragging: default as the initial value of the property,
and makes it a [reset] property. This allows us to change the way the window dragging
region is calculated: Elements with -moz-window-dragging: no-drag will now always be
undraggable, even if they are overlapped by -moz-window-dragging: drag elements. That
way we can keep the region calculation simple and don't have to add code to respect
z-ordering.
--HG--
extra : commitid : GX3ApAyzKi7
extra : rebase_source : 61cab4e535c6c5da75fe79eb1886b6c5b7d136ea
extra : amend_source : 0f461782b8f65eca1009c2f6c192b5b80b908233
By changing signature of those two functions, we make compiler complain about
all their existing uses, so we can find all of them and convert them.
Some of the callsites of Get() with those properties are also converted, but not
all of them. It is fine because if there is any incorrect conversion, compilers
is able to find out now. So they are completely typesafe.
--HG--
extra : source : 808415985d3d446f18941eb007a9be9d69d180ce
This patch makes methods of FramePropertyTable and FrameProperties to be
simple template wrapper functions. Then it converts all references to
FramePropertyDescriptor to use "void" parameter to simulate the current
unsafe behavior.
SmallValueHolder is used for storing small values like int32_t, float,
which can fit in the size of a pointer directly, and thus no lifetime
management is needed.
--HG--
extra : source : 88b2723cddf119d73d8a442d8238b50406e9d604
This makes the state change match the user action. No functionality
changes is expected.
--HG--
extra : commitid : 4MyRasp0lRE
extra : rebase_source : 611819cb3419ffdf76a002d937f3541dc285ef4d
The blur event will hide the carets and produces a standalone selection
highlight without carets. When a user long-pressing on the highlight, we
should show carets for the original selection highlight instead of
select a new word.
The helper UpdateCaretsWithHapticFeedback() should only be needed when
long-pressing. It should suffice to live within SelectWordOrShortcut()
instead of being a member function.
--HG--
extra : commitid : 789VwIRV03I
extra : rebase_source : ef4e9dd1260cec7fd900f68aacdc405bc018b3ce
Both 'auto' and 'auto*' do not change the type inference. However, auto*
make 'self' only accept a pointer which is our intent here.
--HG--
extra : commitid : IvzkNKYE1Q4
extra : rebase_source : 7ea447ff8dae04751afe5ab3e5c84231a5fb8649
This patch (currently WIP) alters the way we determine whether jank is user-visible or not.
Instead of measuring the total time spent doing JS, we now use an
indicator provided by the vsync driver: how long it takes to deliver
the signal from the vsync timer to the main thread. This lets us find
out more accurately if there is user-visible jank. In the future, this
will also let us add an observer to find out whether the process
itself is janky, regardless of JS.
--HG--
extra : rebase_source : a538e3cc9d8904f52d4a0e7bad291189986e4e6d
Displayport margins change by small amounts on almost every single scroll. We do not want to update image visibility nearly that often.
As the comment, and the original bug (bug 1169881) suggest this is only meant to catch rather large changes in display ports as we already have means to trigger an image visibility update via a scroll position change and via any style or layout flush.
This is a regression from bug 1002992 where we switch from the display list builder to the frame tree walker and didn't update mLastUpdateImagesPos in the frame walker.
Native events come with timestamps indicating when they were created or
generated by the user. Using those, we can get a full picture of how long it
takes between the user trying to do something and us responding to it.
This is currently only for ports that populate WidgetEvent's timeStamp
(presently gtk, Windows).
All the event interfaces changed except for nsIDOMUIEvent and its inheritors.
--HG--
extra : transplant_source : %A5U%3F%80%2B%DD%01%F4%D8%21%F2%E9z%C1%D6%AA%CC%D4%EC%F8
We store the original value of duration in AnimationTiming, and add
computed duration in ComputedTiming, so both the Timing model and
AnimationEffectTimingReadOnly can get what they want.
By the way, replace mIterationDuration with mDuration.
--HG--
extra : rebase_source : f8e1fd648572e6d7b1cbecc2ac1888a2f74bbc7e
We want to store the original value from KeyframeEffectOptions whose
iterations is unrestricted double. Therefore, we can get the original value
of iterations by AnimationEffectTimingReadOnly.
By the way, replace mIterationCount with mIterations.
--HG--
extra : rebase_source : da2953056031079c41273ed977545dc926e1b83c
RestyleManager currently has a piece of state for tracking if throttled
animations are up-to-date or not. Actually, it's not so much about throttled
animations but really about outstanding changes to animation styles (which
is typically expected to be due to throttling animations but there are
other cases that invalidate the animation style rule that we should be
considering here).
We now have that same information stored in the EffectCompositor so we can
remove the redundant state from RestyleManager. Furthermore, the state stored
in EffectCompositor is more accurate since it captures the case when animation
style needs to be updated twice within a tick, or when nothing needs to be
updated within a tick.
This patch, therefore, introduces EffectCompositor::HasPendingStyleUpdates in
place of setting RestyleManager::mLastUpdateForThrottledAnimations.
nsTransitionManager also uses mLastUpdateForThrottledAnimations to warn if we
have not processed throttled animations. We can't use HasPendingStyleUpdates
here however, since it will return true in the case where we have triggered new
transitions in the process of restyling. However, any new transitions will
trigger "standard" (i.e. not throttled) restyles so we introduce another
method, HasThrottledStyleUpdates, that returns true only if we have outstanding
throttled updates and use this for the warning inside nsTransitionManager.
nsPresContext contains a mLastStyleUpdateForAllAnimations flag which is simply
used to prevent unnecessarily posting restyles when throttled animations are
already up to date. Since part 13 we now accurately record whether we have
posted a restyle for each throttled animation and only post a restyle if we
have not done so already. As a result, this flag is no longer needed since
calling PostRestyleForThrottledAnimations is effectively a noop when throttled
animations are up-to-date.
Since we want to track elements needing a restyle on EffectCompositor we need
to scope it to an nsPresContext rather than just making if a collection of
static methods.
Even though the content of the root scroll frame is the root element, the primary frame of the root element is never the root scroll frame. This is even true if the normal primary frame of the root element is not created (say because it is display: none). Leaving the primary frame of the root element to be null even though there are frames (the root scroll frame, and the canvas frame) that have the root element as their content.
This behaviour is more consistent by not ignoring a root scroll frame when it exists.
And to several functions above it in the callgraph, ones that no longer need an
nsRenderingContext.
--HG--
extra : rebase_source : 331d00be421316a7071ab4b93894431c36a031d5
We change the color and anti-aliasing on the gfxContext but never do anything
with it while those values are changed.
--HG--
extra : rebase_source : 39ab84c17f8b4b482383464b2b8e0552369fb94c
Instead do it when we first encounter the root scroll frame.
Doing this goes back to bug 635053, where we did it because fixed position items weren't getting included. However in bug 974643 we learned that this was wrong. Displayports aren't relevant to fixed pos content, displayports are only relevant to scrolled content. And we set the dirty rects of fixed pos content specially. The only other thing that should be affected is scrollbars, and we already carefully set their dirty rects too.
