In the process, fixed a few bugs:
- the template eg `{file_adds % "\n{file}"}` produced a leading blank line,
which led to everything being linted.
- 'd' was replaced with 'r' in diff_filters, but the replacement was discarded.
- as a result of the above, `hg status -d` was being used ("show only deleted (but tracked) files") and now it is `hg status -r` ("show only removed files"). I *think* this is what was intended?
Differential Revision: https://phabricator.services.mozilla.com/D66714
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
For the 'Basic password change form' case, the confirm password field should also be true, as selecting the password generation in the popup will fill the same generated password as in the new password field before it without the user having to copy it. Passwords are cached per origin.
There is an existing bug on file to change the text of the autocomplete popup in this case to make that more clear that this is what happens for the confirm password field (Bug 1548854), and other bugs are on file to make it possible to have more than one generated password for the same site in various scenarios (Bug 1569568 and Bug 1551723).
Differential Revision: https://phabricator.services.mozilla.com/D67723
--HG--
extra : moz-landing-system : lando
* Add a new module, NewPasswordModel.jsm, which imports the Fathom library from Bug 1618956, and copies over the Fathom model at [bff6995c32e86...](bff6995c32/new-password/rulesets.js (L6-L272)) into it.
* This module is intended to make it as easy as possible to import model updates from the upstream GitHub repo, though there are a couple extra steps beyond a simple copy and paste.
* The module is imported into LoginAutoComplete.jsm, which has a new helper, _isProbablyANewPasswordField, which runs the model against the provided input element and returns true if the element's confidence score is greater than or equal to a threshold.
* The confidence threshold, specified by the new signon.generation.confidenceThreshold string preference, is currently set to 0.5 based on [this comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1595244#c12).
* This should result in a dramatic reduction in false negative rates compared to the existing implementation of this feature (at the expense of an increase in the false positive rate of the existing feature from ~0% to hopefully around 2%).
* Use of the model is gated behind the same preference used for the confidence threshold, signon.generation.confidenceThreshold.
* This is a string pref that disables the model if its value is "-1". Otherwise, its value should be a string representation of a float [0,1] (e.g. "0.5") which indicates that the model should be enabled with the given confidence threshold.
* Using the model is enabled by default on desktop but disabled by default on mobile (GeckoView) due to Bug 1618058.
* Fixed some existing tests that were broken as a result of this change.
* New test(s) will be added in a subsequent commit.
Differential Revision: https://phabricator.services.mozilla.com/D67068
--HG--
extra : moz-landing-system : lando
When building the search cache, we currently have no idea if engines have been added or modified by a distribution. Therefore we need to skip the corruption check for distributions for now.
One distribution engines are incoporated into the modern configuration, we should no longer have this issue, since we'll know what should and shouldn't be there.
Differential Revision: https://phabricator.services.mozilla.com/D67646
--HG--
extra : moz-landing-system : lando
Regressions from bug 1316748. We had tests for sender.frameId, but they
were all for runtime.sendMessage() and friends. Unfortunatelly, bug 1316748
was split to only deal with Ports, so I sdded some tests to cover this case
as well.
Differential Revision: https://phabricator.services.mozilla.com/D67743
--HG--
extra : moz-landing-system : lando
Also reenable the `static_assert` which was disabled for some reason in
bug 1308236. (Bug 1308236 doesn't contain any information why this assertion
had to be disabled.)
Differential Revision: https://phabricator.services.mozilla.com/D67662
--HG--
extra : moz-landing-system : lando
This removes tracing for the values of the registration map and the active record set and sweeps them instead. This requires maintaining a map of FinalizationRegistryObjects on the zone.
Differential Revision: https://phabricator.services.mozilla.com/D67677
--HG--
extra : moz-landing-system : lando
