Add faviconDataUrl and imagePageUrl to each Snapshot Group so the companion can
directly use these instead of a polyfill for faviconImage and url.
Also change favicon service APIs to respect mDefaultIconURIPreferredSize instead
of always returning the largest icon. This allows to use those APIs more easily
from jsm modules without having to pass around window handles.
Differential Revision: https://phabricator.services.mozilla.com/D143462
This adds a new "engagement" telemetry event for quick suggest results. The
event's object can be the following values:
* "block": The user dismissed ("blocked") the suggestion.
* "click": The user picked the suggestion.
* "help": The user picked the suggestion's help button.
* "impression_only": The user picked some other row.
For this particular bug, we're interested in recording blocks, but there's no
reason not to generalize that idea into an engagement event like this that
records all types of interactions.
Depends on D143254
Differential Revision: https://phabricator.services.mozilla.com/D143331
This does several things:
* Add new scalars for blocked suggestions
* Record the impression custom telemetry ping when a suggestion is blocked
* Remove the code that gets the index of the quick suggest result when the
engagement telemetry is recorded. We can replace all that with simply
`result.rowIndex`, but we need to store the result we last added in a property
to do that, so I replaced `_addedResultInLastQuery` with
`_resultFromLastQuery`
* Modify the urlbar engagement telemetry event code by adding the following
`selType` values: "quicksuggest", "block". We can use the `selType` in the
quick suggest engagement telemetry code to determine whether the block button
or the main part of the row was clicked.
Depends on D143246
Differential Revision: https://phabricator.services.mozilla.com/D143254
This revision does the following:
* Add a new Nimbus variable `quickSuggestBlockingEnabled` with a fallback pref
to show the block button on the usual non-best-match quick suggest rows.
* Previously we supported the block button only on best match rows. This keeps
that, and it also adds a Nimbus variable `bestMatchBlockingEnabled` for it.
We only had a pref for it.
* Change the name of the `browser.urlbar.quickSuggest.blockedDigests` pref to
`browser.urlbar.quicksuggest.blockedDigests` -- i.e., "quicksuggest" should be
in all lowercase, not camel case, since that's what all quick suggest prefs
use. We don't need to worry about a pref migration because blocking has never
been enabled.
* When setting the `browser.urlbar.quicksuggest.blockedDigests` pref, ignore the
resulting `onPrefChanged()` listener call. I do this by keeping a new
`_updatingBlockedDigests` property, similar to `_updatingImpressionStats`
added in D142152.
* Copy the browser_quicksuggest_bestMatch.js test to a new
browser_quicksuggest_block.js test that is specifically for testing blocking.
The new test checks both usual quick suggest rows and best matches.
Depends on D142780
Differential Revision: https://phabricator.services.mozilla.com/D143246
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
In addition, if someone has pdf set to open internally but then disables the pdf viewer, an error occurs when trying to view a pdf. Handle this case by just asking what to do.
Differential Revision: https://phabricator.services.mozilla.com/D143313
This patch changes the default behaviour of `download()`.
- Previous file-based behaviour was moved to `downloadToDisk()` and `deleteFromDisk()`. Existing consumers were migrated to avoid behaviour change.
- `download()` has now `{useCache: true}` by default, option was dropped, and `deleteCached()` is now `deleteDownloaded()`
Differential Revision: https://phabricator.services.mozilla.com/D141980
* Sketch in a page layout and grid to house the tab-pickup region
* Add a tabs-pickup module with custom elements for the deck of cards that is the setup flow
* and a container with placeholder logic to manage the setup flow
* Make myfirefox.js a module, hook up the tabs-pickup element with its controller/manager where we can implement the fxa flow & business logic stuff
Differential Revision: https://phabricator.services.mozilla.com/D142661
* Sketch in a page layout and grid to house the tab-pickup region
* Add a tabs-pickup module with custom elements for the deck of cards that is the setup flow
* and a container with placeholder logic to manage the setup flow
* Make myfirefox.js a module, hook up the tabs-pickup element with its controller/manager where we can implement the fxa flow & business logic stuff
Differential Revision: https://phabricator.services.mozilla.com/D142661
Being able to change the source weights allows for selecting different sources depending on the
UI.
This also moves the pref check for whether to use the new recommendations into the selector.
Differential Revision: https://phabricator.services.mozilla.com/D143029
There are some non-final pieces here that will be improved in the next patch but
this makes most of the changes to how we generate and combine recommendations.
It does not yet sum the source specific scores instead still using the highest
so the same scores show up in tests. The next patch will change the calculation.
Differential Revision: https://phabricator.services.mozilla.com/D142792
The work to filter and select recommendations is somewhat split between
SnapshotSelector and SnapshotScorer right now which can be a little confusing.
This simplifies things a little and makes it a bit more efficient by saying that
the selector is responsible for getting the snapshots from the sources and then
the scorer is reponsible for all the filtering and scoring. They share the
SelectionContext object which tells both what to select.
Differential Revision: https://phabricator.services.mozilla.com/D142790
Fixes for these points from the a11y review of Private Browsing:
-the download button should have a border (color: ButtonText) when it is hovered so the text itself doesn’t bleed into the background
-the border on the close button should use ButtonText
-the google play and app store buttons in the dialog seem to be images, and the images already have borders so adding the button border like we’d normally makes it look fuzzy/visually indistinct. Ideally I’d remove the border from the image and rely on the CSS styling to add the (dynamic) border back in, but we could also remove the border in HCM since this content wont be adaptive anyway (and I think having the additional border here is actually harming the UX)
Differential Revision: https://phabricator.services.mozilla.com/D143092
This adds a new "impression_cap" telemetry event with several things recorded in
the `extra` object. Please see the updated documentation and Events.yaml for
details.
This is another big patch but like D142152 most of it is the test.
Depends on D142152
Differential Revision: https://phabricator.services.mozilla.com/D142780
This implements Suggest impression frequency capping. Capping is performed
separately for sponsored and non-sponsored suggestions. Capping is not
per-suggestion; it's per type of suggestion, either sponsored or non-sponsored.
Capping can be enabled separately for each type. It's disabled by default for
both types with Nimbus variables for each.
Caps are specified in the quick suggest config in remote settings. There are two
kinds of caps: interval and lifetime. Multiple overlapping caps are supported,
for example a per-hour cap, a per-day cap, and a lifetime cap.
The user's impression stats are kept locally and stored in a pref. A "stats
object" corresponding to each cap interval is kept. Each stats object keeps
track of its corresponding cap's interval, the date at which the current
interval period started, and the impression count during the current interval
period. (For the lifetime cap, the interval in the stats object is Infinity.)
Each time a suggestion impression is recorded, the counters in all the
suggestion type's stats objects are incremented. Once a counter for any stats
object is reached, we stop showing that type of suggestion.
When the interval of a stats object has elapsed, its counter is reset. In this
revision, we check for elapsed intervals each time a suggestion is shown. In the
future when we add telemetry in bug 1761058, we will need to record telemetry
events for intervals where caps were not hit, so we may need to do this check
more often (for example near the beginning of `startQuery()`) or even do it on a
repeating timer.
There's some slightly complicated logic for handling changes in the cap config
since it's likely to change over time as we experiment with it (see
`_validateImpressionStats()`).
This revision also makes a few minor improvements unrelated to the bug.
Differential Revision: https://phabricator.services.mozilla.com/D142152
