We landed this backout on mozilla-release for Firefox 85.0.1, but the
problem is still there in 86/87, so let's get this on trunk since the
regression is worse than the initial issue, and doesn't have a
workaround.
Backed out changeset c37b45058138 (bug 1669282)
Differential Revision: https://phabricator.services.mozilla.com/D104986
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
We need to disable current scheme handling under flatpak because it expects
there's system handler for all schemes (which is wrong for example for 'localhost')
until there's a flatpak portal which provides if system has a handler for specific
scheme.
Differential Revision: https://phabricator.services.mozilla.com/D97967
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 patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
While the comment for 'GetFlatpakPortalEnv' said
"We use the same code as gtk_should_use_portal() to detect
if we're in flatpak env", this was not actually true, since the
code only checked whether the environment variable 'GTK_USE_PORTAL'
was set at all, ignoring its value, while the gtk implementation
checks that it is set and that the first character is '1'
(which was already true in the gtk as of the commit that the
comment refers to, [1]).
Adapt it to check for the actual value here, according to what
is also done at [2], so that setting 'GTK_USE_PORTAL=0' or
'GTK_USE_PORTAL=1' in the environment works as expected.
I ran into this while looking at why bug 1517074 still occured
with the native file chooser presumably having been disabled by
starting Firefox using
GTK_USE_PORTAL=0 firefox
with gtk 3.24.20 that does not yet have the fix for gtk issue [3].
[1] e0ce028c88/gtk/gtkprivate.c (L272)
[2] https://searchfox.org/mozilla-central/rev/37932bfc600f97ec923464086dc12cdaa72aefde/widget/gtk/nsFilePicker.cpp#608
[3] https://gitlab.gnome.org/GNOME/gtk/-/issues/1820
Differential Revision: https://phabricator.services.mozilla.com/D80073
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
- Use xdg-desktop-portal for file dialog picker on Wayland as the native one can't use clipboard.
- Ship widget.use-xdg-desktop-portal env variable to force xdg-desktop-portal for both print dialog and file dialog.
Differential Revision: https://phabricator.services.mozilla.com/D74830
Fix nsUnixSystemProxySettings::GetProxyForURI() so it assigns the result to aResult instead of appending to it.
Differential Revision: https://phabricator.services.mozilla.com/D69807
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
--HG--
extra : moz-landing-system : lando
g_app_info_get_default_for_type() will fail on OpenBSD's veiled
filesystem since we most likely don't have direct access to the binaries
that are registered as defaults for this type. Fake it up by just
executing xdg-open via gio-launch-desktop (which we do have access to)
and letting it figure out which program to execute for this MIME type.
This has the side-effect of ignoring/losing MIME types associations
registered in firefox prefs only.
Differential Revision: https://phabricator.services.mozilla.com/D51388
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
There's no need to go through a full nsPrintfCString object, with all
the overhead that implies. Just call AppendInt directly.
Differential Revision: https://phabricator.services.mozilla.com/D25120
--HG--
extra : moz-landing-system : lando
Julien Cristau
Kartik Gautam
Cosmin Sabou
Simon Giesecke
Csoregi Natalia
Christoph Kerschbaumer
Jan Horak
Robert Mader
Ricky Stewart
Bogdan Tara
Dorel Luca
Nathan Froyd
Michael Weghorn
Emilio Cobos Álvarez
Mike Conley
Martin Stransky
Gijs Kruitbosch
Michal Novotny
Sebastian Hengst
Eric Rahm
Gabriele Svelto
joshua stein
Tom Schuster
Mihai Alexandru Michis
Sylvestre Ledru
Mike Hommey
Narcis Beleuzu
Masatoshi Kimura