Add a swatch before angle values in the rules panel and allow cycling
through angle units with shift+click (like we already do for color units).
MozReview-Commit-ID: CWhoUQTkP1G
--HG--
extra : transplant_source : %5B%E5%AD%22%D2%20uk%07%EE%A9%E4%91YS%B3R%C3%DF%21
This patch updates the Source Editor contextmenu's UX. Prior to the
patch, the menu would show the option "Add conditional breakpoint" even
when there was a conditional breakpoint. Now, that option reads "Edit
conditional breakpoint".
Note, the effect of this change varies as follows:
(A) New users:
(B) Existing users who have never opened Settings->Advanced:
- Tabs will restore by default
(D) Existing users who have explicitly set the preference to disabled:
(D) Existing users who visited Settings->Advanced, without explicitly opening this preference:
- Tabs will not restore by default
(The preference already has a value set, hence the default has no effect)
MozReview-Commit-ID: DjMeEcYhusj
I have confirmed that by adding this, we end up calling SwapElements() on the
mPropertyValues member when we build up the nsTArray<Keyframe> result in
GetKeyframeListFromPropertyIndexedKeyframe. Without this explicit move
constructor (i.e. with only the default move constructor) the copy-constructor
for mPropertyValues is called.
MozReview-Commit-ID: 6IWkP97RFUr
--HG--
extra : rebase_source : 4ac4b6545337810a3047f2cfb1dac86074116cfb
StyleAnimationValue::ComputeValue(s) will automatically look up the style
context of the supplied element. This is mostly fine, but when we start using
this method in scenarios where we are building the initial style context
(as happens later in this patch series) it can easily land us in a situation
where we iterate indefinitely.
It would be better, instead, to just explicitly pass in the style context we
want to use, as we already do for StyleAnimationValue::ExtractComputedValue.
MozReview-Commit-ID: ZoVBlBRRBI
--HG--
extra : rebase_source : 9012cc2e405fc887f070fbfaa2f9853289882862
Once we tweak moz.build in the next patch, the grouping in the unified build
will change and expose these missing includes so we fix them here, first.
MozReview-Commit-ID: GebEEociwTo
--HG--
extra : rebase_source : 18158fdf8a3c1a1dcf446118371cad1a15fd4daf
Specifically, for the 'composite' member on keyframes, we now indicate "use the
composite value specified on the effect" using a missing/undefined 'composite'
member as opposed to a null value.
MozReview-Commit-ID: ZH45GvCTlP
--HG--
extra : rebase_source : 5acf081fb844f81280765a87ec019b7847ca1885
Before we begin re-arranging KeyframeEffect.h we move ComputedTiming aside
since putting it in a separate file should make navigating the source
easier.
MozReview-Commit-ID: L5GTFAo00sh
--HG--
extra : rebase_source : e88b6ea092c459afa90831de8469697454e00c5a
This is no longer needed - TransitionAwareCursorLoaderCallbacks was the only
consumer - it was removed as it caused race conditions. The ideal future solution
is probably to use recyclerviews to avoid jank, rather than trying to wait for
transitions to happen.
It's also extremely difficult to use this correctly - the
TransitionAwareCursorLoaderCallbacks simply held the cursor that would usually
be swapped in onLoadFinished until transitions have finished (which is incorrect,
since cursors need to be swapped in before onLoadFinished returns). It's hard to imagine
any alternative solutions, short of avoiding loading cursors in the first place (which
isn't too useful, since cursor loading happens in the background, at which point the UI
status is irrelevant), or hacking the CursorLoader to not return from its worker thread
until UI transitions are done (which would require a new thread-safe implementation of
TransitionsTracker), or maybe even hacking Android Framework's AsyncTaskLoader to not run Loader.deliverResult
while transitions are running (which seems awfully brittle and hacky).
MozReview-Commit-ID: 3JWDcznYL4Y
--HG--
extra : rebase_source : 1b4f52d84b21e4d93ebfb2d5c8d633c6ad12cf8e
extra : histedit_source : 2625e74aa08efa085733d3d34c6a2fa8550cf9f9
TransitionAwareCursorLoaderCallbacks is fundamentally flawed: old CursorLoader
cursors _must_ not be used after onLoadFinished has been called. However
we sometimes queue the cursor swapping (which is implemented by subclasses
in onLoadFinishedAfterTransitions) until after transitions have finished.
CursorLoader.deliverResult() closes the old cursor immediately after calling
onLoadFinished (with the new cursor). At this stage the adapter is
still holding onto the old (but now closed cursor), and will crash if it tries
to read this cursor (which can happen if the adapter is still iterating over the
cursor).
Instead we should ensure that we swap the cursors during onLoadFinished - the simplest
way to do this is by eliminating TransitionAwareCursorLoader and using onLoadFinished
the way the Android framework expects.
It's worth noting that TransitionAwareCursorLoader is obsolete: at the time it was added,
home panels were placed in the HomePagerTabStrip, which notified TransitionsTracker about
its transitions. However HomePagerTabStrip no longer exists, hence there's no need
for us to care about these transitions anymore. (The crash seems to happen because we
try to hide the doorhanger every time we receive LOCATION_CHANGE, and each of these starts
a hide transition - even if no doorhanger is shown - hence we often have a transition
in progress every time we show topsites.)
MozReview-Commit-ID: HsytLpHOrp2
--HG--
extra : rebase_source : 0411e017e19bb4393368b175418a41b0129a622b
extra : histedit_source : 19e68ed7f68180122b7514849b5dad4e246784cb
