`PresShell.h` is exposed as `mozilla/PresShell.h` and `PresShell` is the only
concrete class of `nsIPresShell`. Therefore, we have no reason to access
`PresShell` via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D23277
--HG--
extra : moz-landing-system : lando
try to extend the animation time. I tested this locally on repeat 50 times.
Differential Revision: https://phabricator.services.mozilla.com/D23498
--HG--
extra : moz-landing-system : lando
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
The certificate when exported had filename with no separator. Now added "_" separator to filename.
Differential Revision: https://phabricator.services.mozilla.com/D23492
--HG--
extra : moz-landing-system : lando
When I added AddonTestUtils.initMochiTest to an existing test at
browser/components/preferences/in-content/tests/browser_extension_controlled.js
, the test started to fail often on debug builds, with errors like
"leaked 2 window(s) until shutdown".
Fix this by clearing the global that was saved by initMochiTest.
Differential Revision: https://phabricator.services.mozilla.com/D23502
--HG--
extra : moz-landing-system : lando
This also upgrades apilint to 0.1.8 to enforce that all interfaces have default
impls.
Differential Revision: https://phabricator.services.mozilla.com/D23324
--HG--
extra : moz-landing-system : lando
