This code (and an upcoming dependent patch) is currently behind a pref which is disabled by default, as there is uncertainty as to how it might impact the Dev Tools A11y Panel.
The A11y Panel is currently a moving target due to ongoing refactor for Fission.
This pref should be removed once that groundwork is complete and the impact has been verified.
This patch also includes fixes to some ProxyAccessible methods which previously crashed when there was no parent, as is the case for top level documents.
Without these fixes, the Dev Tools A11y Panel would crash the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D66354
--HG--
extra : moz-landing-system : lando
The special handling of PR_SET_NO_NEW_PRIVS can't be overridden with
Allow(); otherwise every thread in the process will repeatedly apply
copies of the policy to itself until it reaches whatever limits the
kernel imposes, and then we crash so we don't continue execution
seemingly unsandboxed. (See also bug 1257361.)
The prctl policy for the socket process is still allow-all after this
patch; it just prevents crashing the socket process on startup on
kernels before 3.17 (which don't support applying the policy atomically
to all threads).
This patch also adds a comment to try to document this failure mode.
Differential Revision: https://phabricator.services.mozilla.com/D66523
--HG--
extra : moz-landing-system : lando
Changes:
Due to scrollbar and other UI element changes in linux1804 this test was permafailing and was marked as such.
Now that migration has completed for mochitest-plain, re-enable the test with updated pixel count expectations.
Differential Revision: https://phabricator.services.mozilla.com/D66647
--HG--
extra : moz-landing-system : lando
Both PresShell() and PresContext() are cached in nsIFrame. This
simplifies the setup for the callers to
nsCSSFrameConstructor::CreateContinuingFrame().
Differential Revision: https://phabricator.services.mozilla.com/D66600
--HG--
extra : moz-landing-system : lando
The nsPresContext* argument of
nsCSSFrameConstructor::CreateContinuingFrame() is used only to get
PresShell. However, mPresShell is already cached in
nsCSSFrameConstructor (via its base class nsFrameManager).
By switching to use the cached value, we can remove now-unused
nsPresContext* or PresShell* from some continuing-frame-creation
methods' argument list in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D66599
--HG--
extra : moz-landing-system : lando
This should be a minor perf win, since we'll be avoiding needless reallocation.
One minor "purity" drawback: this change means the object can't be immutable
anymore -- we have to drop the `const` keyword from all its members so that it
can be reassigned when it's time to update it. That's fine, though; we only
assign these members atomically (via the constructor or via the implicit
whole-object reassignment operator), so we aren't really losing track of any
bookkeeping via these keyword removals.
Differential Revision: https://phabricator.services.mozilla.com/D66590
--HG--
extra : moz-landing-system : lando
This patch doesn't change behavior; it's effectively just a rename.
Before this patch, we would store instances of the class
"CachedMeasuringReflowResult" in a frame property with the (arbitrary and
nearly-identical) name "CachedFlexMeasuringReflow". These subtly-different
names cause unnecessary confusion & typos.
Let's do away with the custom name for the property table entry, and just name
the entry "CachedMeasuringReflowResult::Prop". This is what we do in
nsGridContainerFrame.cpp for the various frame properties (e.g. Subgrid::Prop),
and it works well for readability there.
Differential Revision: https://phabricator.services.mozilla.com/D66589
--HG--
extra : moz-landing-system : lando
This patch doesn't change behavior. It just renames all ReflowOutput-type
variables to use "reflow output" in their naming, rather than "desired
size". (And it changes two code-comments with s/desired size/reflow-output
measurements/ for consistency.)
I'm doing this because I may want to create a new variable called "desired
size" (or similar) in a later patch, and that's easier if there aren't
similarly-named variables lying around.
Differential Revision: https://phabricator.services.mozilla.com/D66588
--HG--
extra : moz-landing-system : lando
I made more generalized mozSelectableAccessible and
mozSelectableChildAccessible classes for other things that will need
this kind of support.
Differential Revision: https://phabricator.services.mozilla.com/D66304
--HG--
extra : moz-landing-system : lando
Changes:
As documented in bug 1621483, `marionette` experiences a non-trivial amount of issues when run on ubuntu1804 docker image with GTK/GNOME desktop environment enabled.
GTK/GNOME has a higher degree of asynciness when manipulating window size/position and this leads to `marionette` and the derived suite `web-platform-tests-wdspec` reporting intermittent oranges for a number of tests.
While attempts were made to incorporate a fix for the marionette driver itself, the best attempts have only been able to achieve a ~50% reliability in green runs.
This patch reintroduces the use of bare `compiz` window manager exclusively for these two problematic test suites so that at least the tests are running on non-legacy software.
Differential Revision: https://phabricator.services.mozilla.com/D66482
--HG--
extra : moz-landing-system : lando
This is one of the efforts to reduce usage of `ShellExecuteByExplorer`
(bug 1620335).
The purpose of using `ShellExecuteByExplorer` in the scenario to open a
downloaded file is to support applications which are not compatible with
the mitigation policies of our process. When a downloaded file is an
executable, however, we prefer security to compatibility and in particular
we want to prevent binary planting on a user's download directory.
The proposed fix is to go to `ShellExecuteExW` straight if the target
file to launch is an executable.
Differential Revision: https://phabricator.services.mozilla.com/D66325
--HG--
extra : moz-landing-system : lando
Utilizes windowUntils' `sendNativeTouchTap` to simulate double-tap gestures in RDM. Touch gesture simulation will be hidden behind pref until some issues regarding RDM itself are resolved (but are unrelated to this bug). Another important note here is to make sure the pref `devtools.responsive.browserUI.enabled` should be enabled for this.
Differential Revision: https://phabricator.services.mozilla.com/D63335
--HG--
extra : moz-landing-system : lando
This is one of the efforts to reduce usage of `ShellExecuteByExplorer`
(bug 1620335).
The purpose of using `ShellExecuteByExplorer` in the scenario to open a
downloaded file is to support applications which are not compatible with
the mitigation policies of our process. When a downloaded file is an
executable, however, we prefer security to compatibility and in particular
we want to prevent binary planting on a user's download directory.
The proposed fix is to go to `ShellExecuteExW` straight if the target
file to launch is an executable.
Differential Revision: https://phabricator.services.mozilla.com/D66325
--HG--
extra : moz-landing-system : lando
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
This creates a new toolchain artifact that repacks a combination of the
linux64-clang compiler along with parts of the win64-clang-cl compiler.
This has multiple advantages:
- It removes some convoluted parts of build task definitions (limiting
that to only occur on the win-cross toolchain itself).
- It simplifies the build setup by not requiring to prepare for where
clang-cl.exe is.
- It speeds up getting compiler artifacts because the win64-clang-cl
artifact is very large (due to there not being a llvm shared library)
and bzipped, which is slow to decompress. Here, we only take what we
need for the cross builds.
- It adds the runtime files that e.g. PGO will require, and that
linux clang-cl insists lives in the clang directory, not the
win64-clang-cl one, and that would require some convoluted setup to make
it work with the two separate toolchains.
Differential Revision: https://phabricator.services.mozilla.com/D66543
--HG--
extra : moz-landing-system : lando
Fold expressions are more expressive and probably produce better code than the
older template-recursion and initializer_list patterns.
Differential Revision: https://phabricator.services.mozilla.com/D66535
--HG--
extra : moz-landing-system : lando
The files have been removed in bug 1620158, so they won't appear as
differences anymore.
Differential Revision: https://phabricator.services.mozilla.com/D66545
--HG--
extra : moz-landing-system : lando
When we are running from a network drive the new feature in part 1 doesn't work.
So this uses DuplicateHandle instead of OpenThread to get the thread handle used
by the profiler.
It also removes a DuplicateHandle THREAD_ALL_ACCESS call that also fails and a
DuplicateHandle to get a real process handle, which only seems to have been to
fix something on Windows XP.
The handle passed in is always the profiler one, so already has the necessary
permissions. If no thread handle is passed then the pseudo handle is used.
Differential Revision: https://phabricator.services.mozilla.com/D66611
--HG--
extra : moz-landing-system : lando
This adds AddRestrictingRandomSid feature, which fixes our issues with
SetLockdownDefaultDacl, apart from when we are running from a network drive.
Differential Revision: https://phabricator.services.mozilla.com/D66610
--HG--
extra : moz-landing-system : lando