If the login is older than 2 minutes, don't allow revealing the password in the doorhanger.
Differential Revision: https://phabricator.services.mozilla.com/D40434
--HG--
extra : moz-landing-system : lando
The patch:
- changes `privacy.resistFingerprinting.target_video_res` to a static pref;
- changes `privacy.resistFingerprinting.video_frames_per_sec` and
`privacy.resistFingerprinting.video_dropped_ratio` to code constants;
- removes the unused `RFP_TIMER_VALUE_DEFAULT` and `RFP_JITTER_VALUE_DEFAULT`
constants.
Differential Revision: https://phabricator.services.mozilla.com/D40904
--HG--
extra : moz-landing-system : lando
Converts privacy.fuzzyfox.clockgrainus varcache pref to a static pref. This pref used two #define values, which I also removed.
Differential Revision: https://phabricator.services.mozilla.com/D41102
--HG--
extra : moz-landing-system : lando
test_list_json_searchdefault.js is repurposed, as the tests in the searchconfig sub-directory already check the default engine.
Differential Revision: https://phabricator.services.mozilla.com/D41035
--HG--
extra : moz-landing-system : lando
This also renames the existing infallible nsDocShell:GetBrowsingContext()
getter to BrowsingContextRef(), and changes the return type, since several
callers rely on it returning a raw pointer rather than an already_AddRefed.
Differential Revision: https://phabricator.services.mozilla.com/D40312
--HG--
extra : moz-landing-system : lando
Ranges don't cross documents, and there's no reason the typeahead find passes a
shell around. So just don't do it.
This also fixes a bug where references to frames were kept around a flush.
That's potentially unsafe, so I've avoided the flush by passing false to
nsRange.
If something depends on it all the callers need be audited and fixed to handle a
flush properly.
Depends on D40696
Differential Revision: https://phabricator.services.mozilla.com/D40697
--HG--
extra : moz-landing-system : lando
nsTypeAheadFind.cpp contains all of the callsites to this function, so it seems like a logical place for it to live.
Differential Revision: https://phabricator.services.mozilla.com/D40696
--HG--
extra : moz-landing-system : lando
APPLICATION_REPUTATION_BINARY is now replaced by APPLICATION_REPUTATION_BINARY_TYPE,
we can remove it from telemetry.
Depends on D37275
Differential Revision: https://phabricator.services.mozilla.com/D37276
--HG--
extra : moz-landing-system : lando
This patch adds a telemetry, APPLICATION_REPUTATION_BINARY_TYPE, which
records different binary type based on the file extension.
1. BinaryFile, file is considered as a binary file, file is eligible for remote lookup
2. NonBinaryFile, file is not considered as a binary file.
3. MozNonBinaryFile, file is considered as a binary file in Chrome, but we don't
send a download protection ping for this file
4. UnknownFile, file is not in any of the above lists.
Differential Revision: https://phabricator.services.mozilla.com/D37275
--HG--
extra : moz-landing-system : lando
This patch ressurects HiddenFrame.jsm and uses it when handling
the --screenshot command line argument to load the requested page
in a content process. The actual logic for grabbing the image is
also ported to a JSWindowActor. The test for this feature remains
suboptimal as described in the bug.
Differential Revision: https://phabricator.services.mozilla.com/D40148
--HG--
rename : browser/components/shell/HeadlessShell.jsm => browser/components/shell/ScreenshotChild.jsm
extra : moz-landing-system : lando
All built-in engines have migrated from OpenSearch to WebExtensions.
WebExtensions do not support resource: or chrome:-URLs in their
`favicon_url` field, so the "resource:" and "chrome:" URLs can only be
used by external opensearch XML files. These should not rely on internal
resources from omni.ja, as the bug shows. So just drop support for
"chrome:" and "resource:"-URLs, as we don't need them any more.
Current OpenSearch engines that relied on chrome/resource:-URLs can
either replace the URL with a data:-URL, or migrate to WebExtensions.
Differential Revision: https://phabricator.services.mozilla.com/D40345
--HG--
extra : moz-landing-system : lando
This patch ressurects HiddenFrame.jsm and uses it when handling
the --screenshot command line argument to load the requested page
in a content process. The actual logic for grabbing the image is
also ported to a JSWindowActor. The test for this feature remains
suboptimal as described in the bug.
Differential Revision: https://phabricator.services.mozilla.com/D40148
--HG--
rename : browser/components/shell/HeadlessShell.jsm => browser/components/shell/ScreenshotChild.jsm
extra : moz-landing-system : lando
Refactor the gtest code because it confused me while adding new tests.
This patch focus on refining utility function but it also contains other
minor refinements.
Changes includes:
1. Add comments to utility function
2. Move common utility functions to Common.cpp and remove duplicates
3. Header file removal and reorder
4. Unify MPL commnetc
5. Replace anonymouse namespace with static function
Differential Revision: https://phabricator.services.mozilla.com/D37532
--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
This patch introduces a new Rust crate called `static_prefs`.
It also changes generate_static_pref_list.py to generate two new files.
- StaticPrefsCGetters.cpp: contains C getters, which are just wrappers around
the C++ getters. This is included into Preferences.cpp.
- static_prefs.rs: contains declarations for the C getters, plus the `pref!`
macro which provides nice syntax for calling the C getters. This is included
into static_prefs/src/lib.rs.
The new code is only generated for prefs marked with the new `rust` field in
the YAML. It's opt-in because there's no point generating additional code for
900+ static prefs when only about 20 are currently used from Rust.
This patch only marks a single pref (`browser.display.document_color_use`) with
`rust: true`. That pref isn't accessed from Rust code in this patch, but it's
necessary because the generated Rust code is invalid if there are zero
Rust-accessed prefs. (The next patch will access that pref and others from Rust
code.
Differential Revision: https://phabricator.services.mozilla.com/D40791
--HG--
extra : moz-landing-system : lando