Bug 1508522 relaxed async animation size restriction with WebRender. Then test_animation_performance_warning.html also needs to be updated to accept it.
Differential Revision: https://phabricator.services.mozilla.com/D17470
--HG--
extra : moz-landing-system : lando
Skip the test since content side basically does not do painting when WebRender is used and the test depends on content side painting.
Differential Revision: https://phabricator.services.mozilla.com/D17800
--HG--
extra : moz-landing-system : lando
Prevent web_accessible_resources resources loading in private contexts when extension does not have permission.
Differential Revision: https://phabricator.services.mozilla.com/D17138
--HG--
extra : moz-landing-system : lando
It turns out, we don't need to `mk_add_options export` the variables
from the in-tree mozconfigs. If anything, that causes problems when
trying to simplify the mozconfigs, because it makes the variables
exported from .mozconfig.mk, overriding what configure may change and
store in autoconf.mk.
All the variables are handled by configure in a way that makes them
available in autoconf.mk, so there's no loss there, and with the
python/shell-based mozconfig loader, it turns out we don't need to go
through extra normalization via cmd.
autospider.py, being its own pseudo-mozconfig parser, still does need
it, though, but it was hooking into it already, so just inline that.
Differential Revision: https://phabricator.services.mozilla.com/D17769
--HG--
extra : moz-landing-system : lando
Previously, we hardcoded HostX64 because configure would autodetect a
x86 host on x64 machines, but the x86 MSVC compiler wouldn't be
suitable.
While the x86 MSVC compiler might still not be suitable, now that
configure detects x64 hosts properly, when the configure host is
detected as x86, we can't even execute the x64 compiler, so we can at
least try with the x86 one correctly.
Differential Revision: https://phabricator.services.mozilla.com/D17788
--HG--
extra : moz-landing-system : lando
The combination of bug 1515579 and bug 1520394 made things harder for
old-configure, because it doesn't necessarily have a complete view of
the search PATH that has been used. This doesn't actually cause problems
on non-Windows builds because things work out fine, but on Windows,
some of the executions of clang-cl in old-configure insist on being able
to find a MSVC install. That, again, doesn't currently cause problems in
general on local builds because clang-cl finds it through the registry
(presumably), and on automation, because it's in the `mk_add_options
export`'ed PATH, but the latter is due to change.
Depends on D17772
Differential Revision: https://phabricator.services.mozilla.com/D17783
--HG--
extra : moz-landing-system : lando
Also, while here, replace subprocess.check_output with check_cmd_output.
Depends on D17771
Differential Revision: https://phabricator.services.mozilla.com/D17772
--HG--
extra : moz-landing-system : lando
Bug 1520394 changed things such that the configure sandbox is using a
copy of os.environ. So when mozconfig injects environment changes, they
only affect the sandbox. Which means when the which module uses
os.environ to get PATH, it gets the original unmodified environment.
So instead of relying on the which module getting PATH itself, we feed
it with it. It's worth noting that the which module adds `.` on Windows,
but we don't copy this behavior, because in the context of configure,
it's actually not important (`.` would be the topobjdir).
Differential Revision: https://phabricator.services.mozilla.com/D17771
--HG--
extra : moz-landing-system : lando
--host is autodetected and may not actually be what the currently given
values are.
Differential Revision: https://phabricator.services.mozilla.com/D17765
--HG--
extra : moz-landing-system : lando
The crash happens when we try to reparent the absolute/fixed
positioned children to the non-column-span wrapper's absolute list.
When constructing the multicol container, we want it to be the
absolute/fixed position container, not the moz-column-content anonymous
blocks. Hence the modification in AppendFramesToParent() and
ConstructBlock().
Delete AdjustAbsoluteContainingBlock() because we'd like to reparent
absolute/fixed children to non-first continuation of block descendant of
multicol. And it doesn't crash anymore today.
Differential Revision: https://phabricator.services.mozilla.com/D16728
--HG--
extra : moz-landing-system : lando
Don't warn about measurements that aren't available for the current platform.
Differential Revision: https://phabricator.services.mozilla.com/D17862
--HG--
extra : moz-landing-system : lando
Relevant divs are:
* Those that have an ID attribute. This is important so anchors still work.
* Those whose first or last child is a text-only node.
* Those whose first or last child has an inline frame.
We now discard divs that are not display:block; or display:inline-block;. We also discard divs that are part of an anonymous subtree.
We stop creating divs from the eHyperTextType frame type alltogether.
Note that because of shadow DOM properties in the video controls, two additional divs with IDs require role="none" in the media controls widget code.
Differential Revision: https://phabricator.services.mozilla.com/D17348
--HG--
extra : moz-landing-system : lando
I think the `stride < width * bpp` is the right thing to check for, since I
don't know if there's any guarantee of it of the stride being equal, but let me
know if I'm wrong.
Differential Revision: https://phabricator.services.mozilla.com/D17851
--HG--
extra : moz-landing-system : lando
When investigating the timeouts for wikia.com on Google Chrome I discovered differences in the way proxy configuration is interpreted. It meant that insecure sites such as wikia were not using the proxy when launched via mach, and now that wikia.com redirects to a secure site we get redirected to a site that is not in the recordings. I have resolved this by fixing the command line argument for the proxy to include all protocols. It was also necesary to allow communication with the control server by adding localhost to the pass-through hosts.
I also removed the trailing disable-sync command line argument that was introduced recently in error.
Differential Revision: https://phabricator.services.mozilla.com/D17869
--HG--
extra : moz-landing-system : lando
And use it as an alternative to vswhere, instead of the current late
check. This allows to use VC_PATH when using a MSVC archive that is not
installed through the VS installer, and not have to care about PATH.
Depends on D17786
Differential Revision: https://phabricator.services.mozilla.com/D17787
--HG--
extra : moz-landing-system : lando
- Only expose it as well as --with-visual-studio-version when the host
system is Windows.
- Don't run vswhere twice (once for host and once for target).
Depends on D17785
Differential Revision: https://phabricator.services.mozilla.com/D17786
--HG--
extra : moz-landing-system : lando
In some setups, MSVC is not found through vc_compiler_path, so we may
need a more complete path. `toolchain_search_path` contains
vc_compiler_path, as well as $PATH (among others), increasing our
chances.
Also, if we fail to find cl.exe that way, fail early, instead of failing
while processing config.status, failing to serialize MIDL_FLAGS because
it contains a `None`.
Depends on D17767
Differential Revision: https://phabricator.services.mozilla.com/D17768
--HG--
extra : moz-landing-system : lando
This turns out to not work at all, because this prevents MIDL itself to
pass -I to the compiler, which then proceeds to fail. We're just lucky
that our MSVC detection doesn't yield any default flags so this is
effectively dead code.
Differential Revision: https://phabricator.services.mozilla.com/D17767
--HG--
extra : moz-landing-system : lando
