Using a simple |const char*| is more memory-efficient than allocating a
JS string. We still have to allocate the JS string for passing things
into JS, but ideally we will be able to move the point of allocation
much closer to where it's actually needed, rather than indiscriminantly
doing it all the time.
For each of macosx64, linux32, and linux64, this creates a new
base_<platform>.yml file that is then specialized into opt, opt st-in,
artifact, and dbg variants. The base contains the workspace cache,
but the `mach taskcluster-graph` removes it for try jobs.
MozReview-Commit-ID: 7Ndw4NnNZgD
--HG--
rename : testing/taskcluster/tasks/builds/linux64_clobber.yml => testing/taskcluster/tasks/builds/base_linux64.yml
extra : rebase_source : 0199669cce185e449f35259ab596333c0a03bba3
This commit only replace windows-style line endings w/ unix-style ones.
"git diff -w" would see no difference in this commit.
--HG--
extra : commitid : 3L1KflCYhR3
Add this test into web-platform-tests.
Since -webkit-text-fill-color is on compat spec, we might want this
feature to be tested on different browsers.
--HG--
extra : commitid : 3L1KflCYhR3
This commit switches Windows builds from Visual Studio 2013
to Visual Studio 2015 Update 1.
Previously, Visual Studio was installed on the builders as part
of the base system image. Starting with this commit, we obtain
Visual Studio from a pre-generated, self-contained archive
containing the executables, Windows SDK, and other support
files. This means that new Windows toolchains can be installed
without having to modify configuration of machines in automation!
The mozconfigs for Visual Studio 2015 are a bit different from
existing mozconfigs.
Because it appears to be completely redundant and not necessary,
the LIBPATH variable has been dropped.
The order of paths in PATH, LIB, and INCLUDE has changed. The new
order more accurately reflects what would be defined by
vcvarsall.bat.
As part of switching to Visual Studio 2015, the Universal CRT is
now required. So, the 2015 mozconfigs export WIN_UCRT_REDIST_DIR
to define the location to those files.
The switch to Visual Studio 2015 also involves the switch from
the Windows 8.1 SDK to the Windows 10 SDK. However, we still
target an old version of Windows, so this hopefully shouldn't
have any significant fallout.
It's worth noting that switching to Visual Studio 2015 makes
builds - especially PGO builds - significantly faster. Our
PGO build times in automation are ~1 hour faster. Our regular
builds appear to be a few minutes faster.
MozReview-Commit-ID: Pa5GW8V87Q
--HG--
extra : source : 56b27306d3257445f70374aa78fc5bd42ef300ce
extra : intermediate-source : 559a80645f20706e1eaaeed863e90c2d35ff7644
According to dbaron, the deleted block smells like a workaround for
a compiler bug which no longer reproduces in VS2015. This is the last
bug blocking the landing of VS2015. So remove the apparent workaround.
MozReview-Commit-ID: zsmfFjSOxN
--HG--
extra : source : f231263334d44b912e55898be5a1d35381face5b
End state is Waldo's original patch, which so far has been the only
version that compiles on VS2015.
MozReview-Commit-ID: FCOaEvMqYB4
--HG--
extra : source : 8d59e338a5bd76338f0fe28ff589726bc4438fdd
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
Nathan Froyd
Jan-Ivar Bruaroey
Dustin J. Mitchell
Patrick McManus
Jan de Mooij
Jeremy Chen
Phil Ringnalda
Ryan VanderMeulen
Gregory Szorc
JW Wang
Steve Fink
Carsten "Tomcat" Book
Sebastian Hengst
Andrea Marchesini
Mark Capella
Andrzej Hunt
Jonathan Kew
Brian Birtles
Andrzej Hunt
Michael Comella