This allows us to fix a bug where when our current Private Browsing shortcuts are pinned to the Start Menu, they use the regular Firefox Visual Elements (which is the non-Private Browsing logo). I tried to make this as minimal and braindead as possible.
Differential Revision: https://phabricator.services.mozilla.com/D151538
The new icon is not channel-specific, but I've kept it in branding
since it's possible that we'll distinguish in the future.
Differential Revision: https://phabricator.services.mozilla.com/D142396
This patch adds a library that contains an interposer function for
pthread_create(). The interposer will setup an alternate signal stack to
handle crashes - thus enabling us to catch stack overflows - and then call the
real pthread_create() function. Since the interposer needs to appear in the
linker's search order before libpthread we manually link it into firefox,
plugin-container and xpcshell's executables ASAP.
Differential Revision: https://phabricator.services.mozilla.com/D132736
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
In optimized builds, it's stripped out at link time, because it's been
unused since bug 1505445 moved the sandbox initialization into libxul.
But in non-optimized builds, it's not, and that pulls in CoreFoundation
symbols, but we're not linking plugin-container against CoreFoundation
(we do link firefox to it for other uses).
This wasn't a problem before bug 1747160 because we were linking
everything against CoreFoundation (indirectly).
Differential Revision: https://phabricator.services.mozilla.com/D134587
This adds a new cross call using the chromium shared memory IPC to proxy use of
the Uniscribe line breaker, because it cannot be used in the content process
with win32k lockdown enabled.
If the text being processed is too long to fit into the IPC params then it is
processed in chunks.
This change implements an INPTR_TYPE in the sandbox, which appears to have
been removed at some point.
It also fixes a bug in OpcodeFactory::MakeOpAction, so that a null param is
passed and we can use an empty parameter set.
New files are in chromium-shim as these are most likely to require changes and
this means we will not have to update the main chromium patch.
Depends on D129125
Differential Revision: https://phabricator.services.mozilla.com/D126809
We will only run the processes in CET compatible modules only mode when not
using the JIT code. So marking xul.dll as compatible should be OK.
Differential Revision: https://phabricator.services.mozilla.com/D117551
Some places are actually expecting MOZ_GECKODRIVER to be set, rather
than ENABLE_GECKODRIVER, and we more frequently use MOZ_-prefixed
variables, so settle on that.
This fixes browser/app/macbuild/Contents/MacOS-files.txt, which was
expecting MOZ_GECKODRIVER.
Differential Revision: https://phabricator.services.mozilla.com/D106876
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
This simplifies how js gets zlib by simply using the zlib Library
defined in config/external/zlib instead of manually adding MOZ_ZLIB_LIBS
that it needs to inherit somehow correctly from the top-level configure.
The use in browser/app was redundant with mozglue depending on zlib
already.
Differential Revision: https://phabricator.services.mozilla.com/D92720
This happened because the `browser/app/macbuild/Contents/MacOS-files.in` file had the string `firefox-bin` hardcoded, which introduces packaging failures down the line. The naive solution didn't work however because we don't preprocess this file. (This is apparently an error. We SHOULD have been doing this from day one, since this file contains preprocessor directives that are ignored by `rsync` since `#` is its "comment" character.) So preprocess the file and update the `Makefile` accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D86563
This removes the obsolete backend. Notes on some of the less obvious changes
made as part of this patch:
- some of the gFoo style getters in Blocklist.jsm were only used by the XML
version of the blocklist; I've removed them and tried to remove spurious
settings of those properties in the remaining tests.
- some utility methods (e.g. distribution information getters) were also only
used for the XML version (for the update URL).
- it's no longer necessary to test switching implementations.
- in browser/base/content/test/plugins/, we ran some tests from two manifests
in order to run them with both blocklist backends. The simplest way of
reducing this back down to one was to remove the remote-settings one. If I'd
been more future-oriented when I created the duplication, perhaps I would
have moved the XML version out into a different manifest instead, but I
didn't, so now it looks like we're removing the modern one, whereas really
we're going to be running the modern one as part of the "normal" tests and
we're no longer running the "old" tests.
- removed all mentions I could see of extensions.blocklist.url which is no
longer used for anything.
- per https://bugzilla.mozilla.org/show_bug.cgi?id=1016555#c23, updated
references for the OneCRL timing and how it relates to blocklist updates.
Differential Revision: https://phabricator.services.mozilla.com/D64933
--HG--
extra : moz-landing-system : lando
MOZ_PHOENIX was a macro added back in 2002 to differentiate SeaMonkey and Phoenix appshell bits. The earliest references to MOZ_PHOENIX I can find in Gecko's pre-hg history are bug 161448, bug 213228, bug 243091, and 05ef2e9b38.
Differential Revision: https://phabricator.services.mozilla.com/D58358
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Depends on D43156
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
This patch does a few things:
* Fleshes out the launcher process failure ping;
* Sends that ping via pingsender;
* If there is any failure in doing so, we fall back to the Windows event log;
* Any launcher process failures will result in us falling back to the normal
startup code path, ensuring that users will still see a browser.
A sample ping will be attached to the bug.
Differential Revision: https://phabricator.services.mozilla.com/D19697
--HG--
extra : moz-landing-system : lando
This patch does a few things:
* Fleshes out the launcher process failure ping;
* Sends that ping via pingsender;
* If there is any failure in doing so, we fall back to the Windows event log;
* Any launcher process failures will result in us falling back to the normal
startup code path, ensuring that users will still see a browser.
A sample ping will be attached to the bug.
***
Format cleanup
Differential Revision: https://phabricator.services.mozilla.com/D19697
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
Christian Holler (:decoder)
Gabriele Svelto
Sandor Molnar
Narcis Beleuzu
Ryan VanderMeulen
Greg Stoll
Butkovits Atila
Stanca Serban
Ben Hearsum
Nick Alexander
Mike Hommey
Iulian Moraru
Toshihito Kikuchi
Marian-Vasile Laza
Bob Owen
Ricky Stewart
Bogdan Tara
Dorel Luca
Gijs Kruitbosch
Chris Peterson
Aaron Klotz
Brindusan Cristian
Ciure Andrei
Andreea Pavel
Cosmin Sabou