The telemetry result indicate that unexplained install failures are very rare,
so we don't need to bother keeping this probe.
We should still need to check whether the GMP files disappear from disk, as
telemetry indicates this does happen, though quite rarely.
MozReview-Commit-ID: K64tlRajACJ
--HG--
extra : rebase_source : 0778f4bdf85cbd448ca71694c65bd99806307386
The best kind of patch: bulk deletion. This removes two separate but
similar build flags, and an unsupported integration piece. The first
packaged Fennec's resources into an ill-defined GeckoView archive; the
second built on the first to produce an Android ARchive for external
consumption. Neither of these artifacts are supported or have
consumers; in fact, they mislead potential consumers, since they're
known to be broken. The Gradle build work under the --with-gradle
flag, and significant follow-up, is the path forward if Mozilla wants
to invest in packaging GeckoView on Android for external consumption.
That is, rather than hacking together AAR files, we'll use the
well-supported Gradle mechanisms for building and publishing such
libraries.
MozReview-Commit-ID: 4Z1jJ8z0cyJ
--HG--
extra : rebase_source : b8e65f39c286313fe8963bf3832d9b6977ef188f
This means if Widevine is preffed visible on Linux it will show up in the
plugin list.
We only support Mac OSX 10.9 and later, so we don't need the >= 10.7 check any
more.
MozReview-Commit-ID: BjgMKeIIrrI
--HG--
extra : rebase_source : 46740a9d40f8ae700b6a47eb488a2435e48c1e99
We're not going to get a supported Adobe GMP on WinXP, so we shouldn't download
it or show it in our add-on manager.
MozReview-Commit-ID: I3cNsStmzsV
--HG--
extra : rebase_source : b67c7cbec013f83bcf7d24cac99755faf1b5e07e
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
This ended up being a bigger change than I had hoped for but
it updates the WebAPITask helper in amWebAPI.js so that errors
returned from the parent process are immediately wrapped into
Error objects from the content page. In this way, programming
errors or other internal errors don't leak out to mozAddonManager
users.
The way the previous code managed window references using "this"
was already a bit fussy, this patch only makes it worse. But I
think this basic logical structure here is right and since this
bug is responsible for widespread breakage, I'd like to get this
checked in and then clean it up in a follow-up.
MozReview-Commit-ID: 98PgbWKsHIN
--HG--
extra : source : f2cd195ea3898c9c46e7f58bbcaa3292a2793554
If browser.download.forbid_open_with is set to true (default: false)
the download dialog will not ever show the "Open with" option for
opening the file with an external application; only the "Save" and
"Cancel" options will be available.
This is very useful to enable when the browser is sandboxed (e.g. via
AppArmor) in such a way that it is forbidden to run external
applications, since users then are not presented with this choice
which will not work and only cause confusion.
See https://trac.torproject.org/17502
With more recent version of ASAN, the updater program shows multiple
leaks, for different reasons.
One is that the updater code heavily relies on pointers into a large
buffer, with exceptions, making things difficult to avoid leaks of those
exceptions. At least it requires more effort than I'm willing to put for
the sake of upgrading the compiler we use for ASAN.
Another is that the leak suppressions are not currently used for
xpcshell tests, and some leaks attributed to libglib, that would
normally be suppressed, are not.
Moreover, even if the suppressions were used, it looks like some are not
rooted to already suppressed system libraries, and would require
investigation. Ideally, we'd have debug symbols installed for the system
libraries and would have full stack traces, but we don't, so this makes
the whole process harder than necessary.
All in all, the updater is a separate short-lived program, and until we
can address all the problems above, we can just ignore memory leaks in
it (which aren't new anyways and are ignored by not being detected by
the ASAN currently used on automation). We don't disable ASAN entirely,
though, only leak detection, and only for the updater program.