Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : rebase_source : d097342b0c26fb92e5236e83035b87bb7da84321
Current impl at SVGMotionSMILType::Interpolate has some wrong assertions, it's probably caused by overlooking the special behavior of to-animation. These assumptions also lead weird animation in the product build. Now we take to-animation into account, and implement similar behavior as Chrome and Safari.
Differential Revision: https://phabricator.services.mozilla.com/D23095
--HG--
extra : moz-landing-system : lando
Summary:
Returning null here leaves us in an infinite loading state because null is treated as neither
success nor failure.
Reviewers: jlast
Bug #: 1534847
Differential Revision: https://phabricator.services.mozilla.com/D23453
Summary:
If users navigate while source text is loading, we need to ignore existing
cached promises because they may resolve and then not actually set the
resulting source, because the source was deleted from the source list.
We want to explicitly use a new cache entry if we have navigated.
Reviewers: jlast
Bug #: 1534847
Differential Revision: https://phabricator.services.mozilla.com/D23452
Summary:
Splitting up this logic makes us less likely to introduce code that would break
the caching behavior. If you look closely at these changes, you'll notice that
there actually one one early return in this code that would cause us to
exit without clearing the 'requests' cache meaning we could get stuck in
an infinite loading state.
Reviewers: jlast
Reviewed By: jlast
Bug #: 1534847
Differential Revision: https://phabricator.services.mozilla.com/D23451
This should unblock the fuzzers for now, though it's not the ideal solution.
It's the only reasonably easy solution to unblock them though, I think.
We should probably always keep track of the document a stylesheet was associated
with. We'll need that for constructible stylesheets anyway.
That requires some though on how to get the cycle-collection and such right,
though, and I wouldn't be able to write or land that ASAP.
Differential Revision: https://phabricator.services.mozilla.com/D23584
--HG--
extra : moz-landing-system : lando
History does not disclose why we needed this, but in the brave new GCC
6-compiled world, deleting these files means that host links can no
longer find libstdc++, which causes problems. Let's put the files back.
Differential Revision: https://phabricator.services.mozilla.com/D22884
--HG--
extra : moz-landing-system : lando
Firefox itself has moved on to GCC 6.x; we can move our toolchains along too.
Differential Revision: https://phabricator.services.mozilla.com/D22883
--HG--
extra : moz-landing-system : lando
We're going to copy an x86_64-unknown-linux-gnu ld into the clang build,
which clang will then use in preference to things on PATH. We therefore
need to ensure that this ld is the same ld as would be used for other
builds, such as PGO. This change is the most expedient way to do that;
future work will make the gcc job(s) depend on linux64-binutils directly.
Differential Revision: https://phabricator.services.mozilla.com/D22882
--HG--
extra : moz-landing-system : lando
We do this to encourage clang to find an new-enough linker instead of
the system one.
Differential Revision: https://phabricator.services.mozilla.com/D22881
--HG--
extra : moz-landing-system : lando
We want our clang bootstrap to use the GCC headers we're building with,
not whatever sysroot it happens to find on the server we're building on.
The -gcc-toolchain argument we specify when building clang will also be
picked up by llvm-config, so we need to strip it out when building the
plugin. Otherwise, we will get peculiar failures about not being able to
find C++ header files.
Differential Revision: https://phabricator.services.mozilla.com/D22880
--HG--
extra : moz-landing-system : lando
Explicit is better than implicit, and helps ensure that GCC is always
using the binutils we built it with, rather than the system binutils.
Differential Revision: https://phabricator.services.mozilla.com/D22879
--HG--
extra : moz-landing-system : lando
The position of remote browser was not updated by resizing the window and
changing the align of viewport etc, although will be updated when the window
moves, the frame reflows and so on.
Thus, in this patch, update the position of remote browser before showing
context menu so as to locates at proper position.
I investigated though, when reflow and moving happens, the position is updated
by TabParent::UpdateDimensions()[1]. This patch as well is taking an approach
which update the position explicitly by TabParent::UpdateDimensions() before
showing context menu.
[1] https://searchfox.org/mozilla-central/source/dom/ipc/TabParent.cpp#729
Differential Revision: https://phabricator.services.mozilla.com/D23470
--HG--
extra : moz-landing-system : lando
::first-line reparenting may make non-first continuations to get a new style on
which we haven't run StartImageLoads when fragmenting out of the first-line.
Given this was mostly an opportunistic optimization let's remove it rather than
sacrificing correctness.
With bug 1465474 we would be able to fix this...
Differential Revision: https://phabricator.services.mozilla.com/D23525
--HG--
extra : moz-landing-system : lando
Returning null here leaves us in an infinite loading state because null is treated as neither
success nor failure.
Differential Revision: https://phabricator.services.mozilla.com/D23453
--HG--
extra : moz-landing-system : lando
If users navigate while source text is loading, we need to ignore existing
cached promises because they may resolve and then not actually set the
resulting source, because the source was deleted from the source list.
We want to explicitly use a new cache entry if we have navigated.
Differential Revision: https://phabricator.services.mozilla.com/D23452
--HG--
extra : moz-landing-system : lando
Splitting up this logic makes us less likely to introduce code that would break
the caching behavior. If you look closely at these changes, you'll notice that
there actually one one early return in this code that would cause us to
exit without clearing the 'requests' cache meaning we could get stuck in
an infinite loading state.
Differential Revision: https://phabricator.services.mozilla.com/D23451
--HG--
extra : moz-landing-system : lando
(without the dash, because I want *this* push to build)
This filters out all tasks, but that means that several things will still run:
* docker images and tasks they depend on (debian packages)
* always_run tasks (various python-y things)
Differential Revision: https://phabricator.services.mozilla.com/D23020
--HG--
extra : moz-landing-system : lando
Nupur Baghel
Noemi Erli
J.C. Jones
Dave Townsend
Jan Varga
Kriti Singh
Nicolas Silva
Olli Pettay
Lars T Hansen
Zibi Braniecki
Oana Pop Rus
Thomas Nguyen
Tooru Fujisawa
Razvan Maries
violet
Logan Smyth
Emilio Cobos Álvarez
k88hudson
Nathan Froyd
Nathan Froyd
Daisuke Akatsuka
David Walsh
Andreea Pavel
Dustin J. Mitchell
Ricky Rosario