MozReview-Commit-ID: COIK852QzUm
The test also verifies that when an import rule event arrives, that the rule has a loaded stylesheet.
--HG--
extra : rebase_source : ca4e0cece11382ce204d6b9cf0823bf1d66f0255
The initial motivation for this patch, was to prevent command lines that are
too long on Windows. To that end, there is a cap to the number of paths that
can be run per job. For now that cap is set to 50. This will allow for an
average path length of 160 characters, which should be sufficient with room to
spare.
But another big benefit of this patch is that we are running more things in
parallel. Previously, mozlint ran each linter in its own subprocess, but that's
it. If running eslint is 90% of the work, it'll still only get a single
process. This means we are wasting cores as soon as the other linters are
finished.
This patch chunks the number of specified paths such that there will be N*L
jobs where 'N' is the number of cores and 'L' is the number of linters. This
means even when there's a dominant linter, we'll be making better use of our
resources. This isn't perfect of course, as some paths might contain a small
number of files, and some will contain a very large number of files. But it's
a start
A limitation to this approach is that if there are fewer paths specified than
there are cores, we won't schedule enough jobs per linter to use those extra
cores. One idea might be to expand specified directories and individually list
all the paths under the directory. But this has some hairy edge cases that
would be tough to catch. Doing this in a non-hacky way would also require a
medium scale refactor.
So I propose further parallelization efforts be destined for follow-ups.
MozReview-Commit-ID: JRRu13AFaii
--HG--
extra : rebase_source : 6cd73d8b6888723de3410df043f7ed042ba3349f
We still need to explicitly set the progress when loading stops, so the progress
bar animates to completion before updateProgressState hides it, but in all other
cases calling just updateProgressState is enough to set the new progress value.
MozReview-Commit-ID: 9mQr5s83i9F
--HG--
extra : rebase_source : 7ce8751a97ea4220df7f3502c268507cd53a00dc
All they do is clutter up the log with "HighlightsRanking: Skipping invalid
highlight item." entries, so we should just skip them in the query already.
MozReview-Commit-ID: 1ra7LcYxp4m
--HG--
extra : rebase_source : 5f150e9ed5fd293f27f110cd2973525d5b82e86d
The MSVC linker winds up generating import libraries when linking some of
our executables, presumably because they contain functions that are
__declspec(dllexport). By default the import libraries get written
alongside the exe, so we force them to be written to the objdir so they don't
clutter up dist/bin.
MozReview-Commit-ID: 7DTfCo3OdDQ
--HG--
extra : rebase_source : fea69e8f60633b824726269c2296af9fe812d3ed
Historically we built all our binaries in directories in the objdir, then
symlinked them into dist/bin. Some binaries needed to be copied instead
so that certain relative path lookups work properly, so we resorted to
sprinkling `NSDISTMODE=copy` around Makefiles.
This change makes it so we build PROGRAMs (not any other sort of targets)
directly in dist/bin instead. We could do the same for our other targets
with a little more work.
There were several places in the tree that were copying built binaries to
some other place and needed fixup to match the new location of binaries.
On Windows pdb files are left in the objdir where the program was
originally linked. symbolstore.py needs to locate the pdb file both to
determine whether it should dump symbols for a binary and also to copy
the pdb file into the symbol package. We fix this by simply looking for
the pdb file in the current working directory if it isn't present next
to the binary, which matches how we invoke symbolstore.py.
MozReview-Commit-ID: 8TOD1uTXD5e
--HG--
extra : rebase_source : 9140be949b206bb595d9188ce7e8357347ecd9a9
This is a small piece of cleanup that turned out to not be strictly
necessary for the rest of this, so I've made it a separate commit.
Sandbox-related launch adjustments (currently, interposing libc
functions and providing a file descriptor for the syscall reporter)
are no longer applied to processes that won't be sandboxed. The
MOZ_SANDBOXED environment variable communicates this to the child
process, which allows SandboxEarlyInit to be skipped in that case as
well. The idea is that disabling sandboxing for a process type, as part
of troubleshooting, should disable everything sandbox-related.
As a side-effect, this also skips some very minor but unnecessary
overhead for NPAPI process startup.
MozReview-Commit-ID: D0KxsRIIRN
--HG--
extra : rebase_source : 89836bea80d0a171324a8e3ff15c6b8e2a163ea9
Namespace isolation is now handled by using clone() at process creation
time, rather than calling unshare.
pthread_atfork will no longer apply to sandboxed child processes.
The two significant uses of it in Firefox currently are to (1) make
malloc work post-fork, which we already avoid depending on in IPC and
sandboxing, and (2) block SIGPROF while forking, which is taken care of;
see SandboxFork::Fork for details. Note that if we need pthread_atfork
in the future it could be emulated by symbol interposition.
clone() is called via glibc's wrapper, for increased compatibility vs.
invoking the syscall directly, using longjmp to recover the syscall's
fork-like semantics the same way Chromium does; see comments for details.
The chroot helper is reimplemented; the general approach is similar,
but instead of a thread it's a process cloned with CLONE_FS (so the
filesystem root is shared) from the child process before it calls
exec, so that it still holds CAP_SYS_CHROOT in the newly created user
namespace. This does mean that it will retain a CoW copy of the
parent's address space until the child starts sandboxing, but that is a
relatively short period of time, so the memory overhead should be small
and short-lived.
The chrooting now happens *after* the seccomp-bpf policy is applied;
previously this wasn't possible because the chroot thread would have
become seccomp-restricted and unable to chroot. This fixes a potential
race condition where a thread could try to access the filesystem after
chrooting but before having its syscalls intercepted for brokering,
causing spurious failure. (This failure mode hasn't been observed in
practice, but we may not be looking for it.)
This adds a hidden bool pref, security.sandbox.content.force-namespace,
which unshares the user namespace (if possible) even if no sandboxing
requires it. It defaults to true on Nightly and false otherwise, to
get test coverage; the default will change to false once we're using
namespaces by default with content.
MozReview-Commit-ID: JhCXF9EgOt6
--HG--
rename : security/sandbox/linux/LinuxCapabilities.cpp => security/sandbox/linux/launch/LinuxCapabilities.cpp
rename : security/sandbox/linux/LinuxCapabilities.h => security/sandbox/linux/launch/LinuxCapabilities.h
extra : rebase_source : f37acacd4f79b0d6df0bcb9d1d5ceb4b9c5e6371
This is mostly deletion, except for SandboxEarlyInit. The unshare()
parts are going away, and the "unexpected threads" workaround can go away
along with them, but the signal broadcast setup still needs to happen
early so we can prevent blocking the signal.
So, SandboxEarlyInit's contract changes slightly from "call before
any other threads exist" to "before any threads that might block all
signals", and everything that can be deferred to immedately before
sandbox startup is. As a result, some getenv()s change to PR_GetEnv
because there can be threads, and there is now an NSPR dependency.
(This may mean that mozglue can no longer interpose symbols in NSPR,
because libmozsandbox is preloaded, but I don't think we're doing that.)
MozReview-Commit-ID: 7e9u0qBNOqn
--HG--
extra : rebase_source : 1a8442f7e0e26231ecf01b19078433d1b5b2763c
2017-08-31 20:38:25 -06:00
Marco Bonardo ext:(%20%3Cmbonardo%40mozilla.com%3E)
Rather then trying to guess options from the parent or the root node, make query nodes directly
inherit some options from their parent.
MozReview-Commit-ID: 1YgDjrrMqGY
--HG--
extra : rebase_source : 5714e6243b0080c977cf6ab454c3f624990414dd
Call PreventNativeKeyBindings() for all key events to prevent triggering
an assertion in PuppetWidget.
MozReview-Commit-ID: 3x96p9baTze
--HG--
extra : rebase_source : 1f1477074e49ca7be9b3f3956289adf4f288a223
FormHistory.shutdown was called via FormHistoryStartup.js's profile-before-change
observer to close the database synchronously.
Now FormHistory uses AsyncShutdown and closes the database asynchronously, so
FormHistory.shutdown is no longer required.
MozReview-Commit-ID: Lok5vx1dOTW
--HG--
extra : rebase_source : c368ab3895fd0c4f39d01d195578afdcf49a5f91
Gurzau Raul
Ed Lee
Brad Werth
Julian Descottes
Andrew Halberstadt
Kartikaya Gupta
Jan Henning
Emilio Cobos Álvarez
abhinav
Ted Mielczarek
Jed Davis
Marco Bonardo ext:(%20%3Cmbonardo%40mozilla.com%3E)
Alexandre Poirot
Jan Odvarko
Jared Wein
Jim Chen
Mike Conley
Narcis Beleuzu