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
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
This way we get the correct values for start-up prefs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D51061
--HG--
extra : moz-landing-system : lando
The XRE_EXECUTABLE_FILE directory entry gives us the actual path that the binary
was launched with. On systems where the filesystem is case insensitive this
can be in any case, which ends up being a different install hash. This patch
ensures that we get the correct case for the install path before generating the
hash.
We have the problem of users who are already affected by this issue. This patch
also leaves the old hash available, if no default profile is found for the
correct hash then we also check for a profile for the old hash, if so we use it
for this hash going forwards. Testing this is kind of a pain, we have to add a
way to override the old hash that we will check against. I'm not totally happy with
how it is done here but not sure there is anything better.
This also adds a test that calling xpcshell with differing cases returns the
same install hash.
Differential Revision: https://phabricator.services.mozilla.com/D34774
--HG--
extra : source : 1a595782402c95aa1f7b26e892e38a500ebb9a77
extra : amend_source : 749b03b93cd4687a83cd696a5cbedc9f2ebc69fc
extra : histedit_source : 459eae02e0e953d5108fd6d7609d9e640eeb695e%2C9fdaaec17723a5e1e7d277d08cd41d16da99437f
The XRE_EXECUTABLE_FILE directory entry gives us the actual path that the binary
was launched with. On systems where the filesystem is case insensitive this
can be in any case, which ends up being a different install hash. This patch
ensures that we get the correct case for the install path before generating the
hash.
We have the problem of users who are already affected by this issue. This patch
also leaves the old hash available, if no default profile is found for the
correct hash then we also check for a profile for the old hash, if so we use it
for this hash going forwards. Testing this is kind of a pain, we have to add a
way to override the old hash that we will check against. I'm not totally happy with
how it is done here but not sure there is anything better.
This also adds a test that calling xpcshell with differing cases returns the
same install hash.
Differential Revision: https://phabricator.services.mozilla.com/D34774
--HG--
extra : rebase_source : 43277e55337f9198b0ec0e6ef8d03ece61c1c5a7
The XRE_EXECUTABLE_FILE directory entry gives us the actual path that the binary
was launched with. On systems where the filesystem is case insensitive this
can be in any case, which ends up being a different install hash. This patch
ensures that we get the correct case for the install path before generating the
hash.
We have the problem of users who are already affected by this issue. This patch
also leaves the old hash available, if no default profile is found for the
correct hash then we also check for a profile for the old hash, if so we use it
for this hash going forwards. Testing this is kind of a pain, we have to add a
way to override the old hash that we will check against. I'm not totally happy with
how it is done here but not sure there is anything better.
This also adds a test that calling xpcshell with differing cases returns the
same install hash.
Differential Revision: https://phabricator.services.mozilla.com/D34774
--HG--
extra : moz-landing-system : lando
Rather than attempting to determine when the Once policy StaticPrefs should be set we initialize them when one of the getter gets called. They become immutable after that.
In a future change we will prevent those values to ever be changed once they have been initialized.
Differential Revision: https://phabricator.services.mozilla.com/D33440
--HG--
extra : moz-landing-system : lando
Uses a different profile depending on the install directory of the application.
installs.ini is used to map a hash of the install directory to a profile
directory.
If no profile is marked as default for the current install we use a heuristic
explained in the code to decide whether to use the profile that would have
been used before this feature.
The feature is disabled in snap builds where the install directory changes for
every version of the app, but multiple instances cannot share profiles anyway.
A boolean flag is used to turn on the feature because in a later patch we need
to be able to turn off the behaviour at runtime.
Includes code folded in from bug 1518634, bug 1522751, bug 1518632 and bug 1523024.
--HG--
extra : rebase_source : 0250c70e992fd8369e52ccee3755cf116a894791
extra : intermediate-source : e69cac07b209ad4ef4229815ffd8138ed64c348e
extra : source : e406bf0bcd665bd0e54ddb13d9ae880004badef1
Uses a different profile depending on the install directory of the application.
installs.ini is used to map a hash of the install directory to a profile
directory.
If no profile is marked as default for the current install we use a heuristic
explained in the code to decide whether to use the profile that would have
been used before this feature.
The feature is disabled in snap builds where the install directory changes for
every version of the app, but multiple instances cannot share profiles anyway.
A boolean flag is used to turn on the feature because in a later patch we need
to be able to turn off the behaviour at runtime.
Includes code folded in from bug 1518634, bug 1522751, bug 1518632 and bug 1523024.
--HG--
extra : rebase_source : b4608f6e8800af4f154daf0e0262f521c8ebd9fd
extra : intermediate-source : ba34b021c8e995ec7fc7c7fbb3dcc5dcf268278c
extra : source : e406bf0bcd665bd0e54ddb13d9ae880004badef1
Currently nsAppRunner is responsible for choosing or creating a profile to use
at startup. It then has to create a reset profile if necessary and lock the
selected profile directories. But these latter things are done in different
places of the selection code and done in different ways, sometimes we delay
while trying to get the lock, sometimes we don't.
This patch moves the profile selection part of the code to its own function so
that then we only have to have one place that does the profile reset and
locking logic.
It makes a lot of sense to have the selection code live in the profile service.
It can use information from the database load to help make the choices and it
also means that we can expose the profile selection code through xpcom allowing
it to be easily automatically tested. It will also be more important for future
patches for the dedicated profiles feature.
Differential Revision: https://phabricator.services.mozilla.com/D16116
--HG--
extra : moz-landing-system : lando
Due to UNIFIED_SOURCES, some missing "mozilla::" namespace qualifications in
nsXREDirProvider.cpp don't cause build errors. Fixing this for correctness and
to avoid build errors if the sources are separated.
Differential Revision: https://phabricator.services.mozilla.com/D10208
--HG--
extra : moz-landing-system : lando
Changes GetCommonUpdateDirectory to always return a directory under ProgramData\Mozilla\updates on Windows
Changes getMockUpdRootDWin to always return ProgramData\Mozilla\updates for the new updates dir location
Removed code that is no longer used in getMockUpdRootDWin
Fixes a build time warning that get_relative_path is not used in updater.cpp
This change applies to Windows only.
Firefox will need to migrate the directory from the old location to the new location. This will be done only once by setting the pref `app.update.migrated.updateDir2.<install path hash>` to `true` once migration has completed.
Note: The pref name app.update.migrated.updateDir has already been used, thus the '2' suffix. It can be found in ESR24.
This also removes the old handling fallback for generating the update directory path. Since xulrunner is no longer supported, this should no longer be needed. If neither the vendor nor app name are defined, it falls back to the literal string "Mozilla".
The code to generate the update directory path and the installation hash have been moved to the updatecommon library. This will allow those functions to be used in Firefox, the Mozilla Maintenance Service, the Mozilla Maintenance Service Installer, and TestAUSHelper.
Additionally, the function that generates the update directory path now has extra functionality. It creates the update directory, sets the permissions on it and, optionally, recursively sets the permissions on everything within.
This patch adds functionality that allows Firefox to set permissions on the new update directory on write failure. It attempts to set the permissions itself and, if that fails and the maintenance service is enabled, it calls into the maintenance service to try from there. If a write fails and the permissions cannot be fixed, the user is prompted to reinstall.
Differential Revision: https://phabricator.services.mozilla.com/D4249
--HG--
rename : toolkit/mozapps/update/updater/win_dirent.cpp => toolkit/mozapps/update/common/win_dirent.cpp
rename : toolkit/mozapps/update/tests/unit_aus_update/cleanupSuccessLogMove.js => toolkit/mozapps/update/tests/unit_aus_update/updateDirectoryMigrate.js
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
