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.
Temporarily rename GetDisplayPort to GetDisplayPortRelativeToScrollPort for the duration of this patchset.
This means that every caller of GetDisplayPort is guaranteed to be touched by this patchset (assuming it compiles), and thus each call site can be checked in review to make sure it is relative to the correct coordinate system.
This makes the one caller that needs the displayport rect have to ask for it seperately.
The reason for this is later in the patch series we need to add "RelativeToScrollFrame/Port" to all displayport getters, but there is no semantically good way to do that to the name GetOrMaybeCreateDisplayPort.
This makes the one caller that needs the displayport rect have to ask for it seperately.
The reason for this is later in the patch series we need to add "RelativeToScrollFrame/Port" to all displayport getters, but there is no semantically good way to do that to the name ViewportHasDisplayPort.
XUL documents don't have a root scroll frame, so this would early return and prevent any of the tiling and max texture size code from running.
The root element of XUL documents likely only ever has zero-margin displayports, and they are not scrollable, so it may not be important.
It doesn't need to store the nsIContent. It just needs to record if mPointerId
has been set. This is because ReleasePointerCapturingContent() doesn't use its
second parameter.
--HG--
extra : rebase_source : d31036c74b06143d88848f63165cd1f41b433102
The CurrentMatrix()-to-GetTransform() change in GetBlurAndSpreadRadius() is
valid because the operations performed on the resulting |transform| only
consult the _11, _12, _21 and _22 members; not the _31 and _32 members (which
are different in gfxContext vs. DrawTarget).
--HG--
extra : rebase_source : 4f40eb223e3e2153607c9c336fc1c850d0e1776f
