This changes the way crash reports for child processes happening too early
during the child process' startup. Before bug 1547698 we wrote a partial
.extra file with those crashes that lacked the process type. The user would
not be notified of those crashes until she restarted Firefox and even when
submitted those crashes would be erroneously labeled as browser crashes.
After bug 1547698 we stopped writing .extra files entirely for those crashes
which left orphaned .dmp files among the pending crash reports.
This patch does three things to improve the situation:
* It writes a partial .extra file so that the crashes are detected at the next
startup. So the user is still not notified directly of these crashes but she
can report them later.
* It adds the process type to the .extra file so that the crash reporters are
labelled correctly.
* It fixes a leak in the `pidToMinidump` hash-map. Since the crashes were
not finalized the `ChildProcessData` strucutre associated with them would
never be fred.
Differential Revision: https://phabricator.services.mozilla.com/D40810
--HG--
extra : moz-landing-system : lando
This patch modifies `DllServices::Get()` to use a magic static to initialize
itself, thus ensuring atomicity and thread safety.
We also remove a redundant kung-fu death grip, as it causes
`DllServices->EnableFull` to reenter `DllServices::Get` but is unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D40891
--HG--
extra : moz-landing-system : lando
When checking for an update during startup, open the update.status file with read and write access so repeated update attempts are prevented when there is only read access to the update.status file.
When loading the active-update.xml file after startup, open it with both read and write access so the active-update.xml isn't loaded when there is only read access and the client will still receive manual update notifications.
On Windows, when opening the active-update.xml file with both read and write access fails attempt to fix the update directory permissions.
When checking if it is possible to apply updates, first check for write access to the update directory so OS X no longer always returns true and Windows no longer always returns true when the maintenance service can be used.
Sets security.turn_off_all_security_so_that_viruses_can_take_over_this_computer to true in the app update xpcshell tests so Cu.isInAutomation is true when running the tests.
Differential Revision: https://phabricator.services.mozilla.com/D39601
--HG--
rename : toolkit/mozapps/update/tests/unit_base_updater/marAppApplyUpdateSuccess.js => toolkit/mozapps/update/tests/unit_base_updater/marAppApplyUpdateSkippedWriteAccess_win.js
extra : moz-landing-system : lando
This patch addresses both Bug 1551913 and Bug 1552206.
This patches the update directory permission-fixing code.
This also fixes a related bug that I discovered while testing this patch: nsAutoSid doesn't actually work because both PSID and HANDLE are both typedef'ed from void*, so the compiler can't actually tell the difference between them and ends up calling CloseHandle instead of FreeSid. To fix this, I removed nsAutoSid and replaced it with UniqueSidPtr, a UniquePtr type that uses a custom deleter class to free the SID properly.
Differential Revision: https://phabricator.services.mozilla.com/D34941
--HG--
rename : toolkit/mozapps/update/common/win_dirent.cpp => toolkit/mozapps/update/common/updateutils_win.cpp
rename : toolkit/mozapps/update/common/win_dirent.h => toolkit/mozapps/update/common/updateutils_win.h
extra : moz-landing-system : lando
This makes it so Mac OS X launches the updater inside of the bundle instead of copying to the update directory.
Cleans up some of the returns in nsUpdateDriver.cpp
Fixes the eslint no-useless-concat exceptions in the update tests
Differential Revision: https://phabricator.services.mozilla.com/D37374
--HG--
extra : moz-landing-system : lando
Using a single-threaded apartment creates a race condition that triggers a
crash in a11y when it hooks InSendMessageEx. Since we're on a background thread,
we don't have a strongly compelling reason to use an STA when an MTA will work
just fine.
Differential Revision: https://phabricator.services.mozilla.com/D36677
--HG--
extra : moz-landing-system : lando
On Mac, remove the "com.apple.quarantine" extended attribute from the updater after it is copied to the staging area. Required on macOS 10.15 which has new restrictions on launching quarantined applications.
Differential Revision: https://phabricator.services.mozilla.com/D35972
--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