We know that some GV installations (particularly but not exlcusively Focus) are
failing to load `libxul.so` during early Gecko bootstrapping. Unfortunately
a boolean pass/fail result is not giving us sufficient information to be able to
properly troubleshoot this problem.
This patch adds `mozilla::Result`-based return values to `XPCOMGlueLoad` and
`GetBootstrap` in an effort to produce more actionable information about these
failures.
We include either a `nsresult` or, if the failure is rooted in a dynamic linker
failure, appropriate platform-specific error information:
* On Unix-based platforms, a `UniqueFreePtr<char>` containing the string from `dlerror(3)`;
* On Windows, the Win32 `DWORD` error code from `GetLastError()`.
For non-Android platforms, I updated them to handle the new return type, but
otherwise did not make any further changes.
For Android, we include the error information in the message string that we pass
into the Java `Exception` that is subsequently thrown.
Differential Revision: https://phabricator.services.mozilla.com/D104263
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
In the initial patches for bug 1656526, mhowell noticed that for startups which
take a very long time, if the user interacts with the skeleton UI window, the OS
will flag us as not responsive, which could be a poorer user experience than
seeing nothing. Since our UI is designed to look non-interactive anyway, we
assume that a better experience would be to simply squash the not responsive
response from the OS by trivially processing native events. It's not perfect in,
say, the event that startup is hung for some reason, but it's arguably preferable
to our old model of startup being hung, which was just nothing being displayed at
all.
Differential Revision: https://phabricator.services.mozilla.com/D91005
This is being added to facilitate moving generation of the update URL to Rust (Bug 1567286). Once that has been completed, we should be able to remove the update URL from its current location in firefox.js so that it is not being duplicated in application.ini.
Differential Revision: https://phabricator.services.mozilla.com/D43300
--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
For now, there is no flag to actually allow it, but this is the
code-side changes to allow the linker being disabled.
Differential Revision: https://phabricator.services.mozilla.com/D54074
--HG--
extra : moz-landing-system : lando
* CreateFileW will return INVALID_HANDLE_VALUE (-1) on failure, not NULL (0).
* MapViewOfFile will map the entire section if the size is 0. No explicit size
is required.
* If SEC_IMAGE is specified, the mapped image size may be different from the
file size on the storage.
Differential Revision: https://phabricator.services.mozilla.com/D32563
--HG--
extra : moz-landing-system : lando
Temporarily just sidestep the issue in bug 1546498 (crash with latest SDK
on startup in Windows 7) by just continuing to use the old method in
Windows 7. We saw no wins in telemetry for Windows 7 anyway, so we should
investigate why that is, and why we see a mysterious crash in the fallback
code, in a followup bug.
Differential Revision: https://phabricator.services.mozilla.com/D29239
--HG--
extra : moz-landing-system : lando
Temporarily just sidestep the issue in bug 1546498 (crash with latest SDK
on startup in Windows 7) by just continuing to use the old method in
Windows 7. We saw no wins in telemetry for Windows 7 anyway, so we should
investigate why that is, and why we see a mysterious crash in the fallback
code, in a followup bug.
Differential Revision: https://phabricator.services.mozilla.com/D29239
--HG--
extra : moz-landing-system : lando
Our old approach was reading this into a region of unexecutable memory,
meaning when we actually loaded the library it needed to be loaded into
executable memory. This fixes that. I suspect that any gains we were
seeing previously were due to hardware effects.
Differential Revision: https://phabricator.services.mozilla.com/D26018
--HG--
extra : moz-landing-system : lando
There shouldn't be any need to do this for content processes as
the DLL should already be in the system file cache.
Differential Revision: https://phabricator.services.mozilla.com/D26017
--HG--
extra : moz-landing-system : lando
This is just to make it simpler to use PrefetchVirtualMemory in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D26016
--HG--
extra : moz-landing-system : lando
Our old approach was reading this into a region of unexecutable memory,
meaning when we actually loaded the library it needed to be loaded into
executable memory. This fixes that. I suspect that any gains we were
seeing previously were due to hardware effects.
Differential Revision: https://phabricator.services.mozilla.com/D26018
--HG--
extra : moz-landing-system : lando
There shouldn't be any need to do this for content processes as
the DLL should already be in the system file cache.
Differential Revision: https://phabricator.services.mozilla.com/D26017
--HG--
extra : moz-landing-system : lando
This is just to make it simpler to use PrefetchVirtualMemory in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D26016
--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
This was necessary back when it still contained a lot of xpcom code, but
shouldn't be necessary now that it only contains two objects.
Differential Revision: https://phabricator.services.mozilla.com/D15168
--HG--
extra : moz-landing-system : lando
> dom/media/gmp/CDMStorageIdProvider.cpp(63,10): warning:
> local variable 'storageId' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/DisplayItemClip.cpp(581,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/DisplayItemClipChain.cpp(88,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/nsDisplayList.cpp(179,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> gfx/thebes/gfxWindowsPlatform.cpp(454,10): warning:
> moving a local object in a return statement prevents copy elision [-Wpessimizing-move]
Will remove std::move().
> gfx/thebes/gfxFontEntry.cpp(245,20): warning:
> local variable 'name' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> netwerk/cookie/nsCookieService.cpp(4460,10): warning:
> local variable 'path' will be copied despite being returned by name [-Wreturn-std-move]
GetPathFromURI() result is stored in an nsAutoCString, so it might as well return that type.
> toolkit/components/extensions/WebExtensionPolicy.cpp(462,12): warning:
> local variable 'result' will be copied despite being returned by name [-Wreturn-std-move]
> toolkit/components/extensions/WebExtensionPolicy.cpp(475,10): warning:
> local variable 'result' will be copied despite being returned by name [-Wreturn-std-move]
`result` may be empty or may be arbitrarily long, so I'll use nsCString inside the function.
> toolkit/xre/CmdLineAndEnvUtils.h(349,10): warning:
> moving a local object in a return statement prevents copy elision [-Wpessimizing-move]
Returning an UniquePtr, will remove std::move().
Also will `return s` instead of `return nullptr` when `(!s)`, to avoid extra construction which could also prevent elision (not entirely sure, but it's at least not worse!); and it's clearer that the two `return`s return the same already-constructed on-stack object.
> tools/profiler/core/shared-libraries-win32.cc(111,10): warning:
> local variable 'version' will be copied despite being returned by name [-Wreturn-std-move]
nsPrintfCString -> nsCString, will add std::move().
> xpcom/glue/FileUtils.cpp(179,10): warning:
> local variable 'fullName' will be copied despite being returned by name [-Wreturn-std-move]
> xpcom/glue/FileUtils.cpp(209,10): warning:
> local variable 'path' will be copied despite being returned by name [-Wreturn-std-move]
nsAuto{,C}String -> ns{,C}String, will add std::move().
This allowed removals of 'AllowCompilerWarnings' from layout/painting,
netwerk/cookie, and toolkit/components/extensions.
Differential Revision: https://phabricator.services.mozilla.com/D5425
--HG--
extra : moz-landing-system : lando
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
These methods will be used in subsequent patches.
MozReview-Commit-ID: EqCpRbn2Y5Y
--HG--
extra : rebase_source : 4b6c2388acb31490a981ca08ba34d4e69c09eddf
The std::nothrow variant of operator new is effectively a fallible
operator new. It is used in third party code.
The duplication with our own fallible operator new is unfortunate, and
we can reduce it by making one an alias of the other.
We keep the fallible library as a dummy on Android because bug 1423802
induces some linking problems.
--HG--
extra : rebase_source : d7b915aaafde40057e87b7ad4bbd82d348e4f12d
Aaron Klotz
Ricky Stewart
Bogdan Tara
Dorel Luca
Florian Quèze
Doug Thayer
Simon Giesecke
Nathan Froyd
Kirk Steuber
Gabriele Svelto
Mike Hommey
Christian Holler
Masatoshi Kimura
Sylvestre Ledru
Cosmin Sabou
Ehsan Akhgari
Gerald Squelart
Henri Sivonen
Panos Astithas
Gurzau Raul
Eric Rahm
Chris Manchester