This is a quick fix to ensure that the search install panel is shown when an extension uses is_default. The intention is to uplift for 64.
Differential Revision: https://phabricator.services.mozilla.com/D13078
--HG--
extra : moz-landing-system : lando
Normally, permission prompts would define a permissionKey attribute in order
to get integrated with SitePermissions. Since SitePermissions is internally
hooked up to TemporaryPermissions, such permission prompts do not need any
extra handling for taking benefit from the temporary permissions infrastructure.
For the Storage Access API, however, we're not going to use SitePermissions,
and instead Gecko will be in charge of defining the required permissions in the
permission manager database when the prompt is responded to with an Allow
action. This means that by default we won't be integrated with the temporary
permissions setup either.
This patch allows prompts to define a new way to opt out of reading and writing
permissions through the permission manager but still being integrated with
temporary permissions. That is, through returning false from the new
usePermissionManager attribute and returning a name from the permissionKey
attribute. TemporaryPermissions will do the expected work in order to ensure
that each prompt with a unique key will be automatically blocked if a previous
instance of the same prompt type with the same key has been blocked in the
current tab.
Note that this doesn't yet include support for showGloballyBlocked or
permitTemporaryAllow since those features aren't needed for our use case.
Differential Revision: https://phabricator.services.mozilla.com/D12466
--HG--
extra : moz-landing-system : lando
The search handler was being called when focusing the menuitem with the keyboard on Windows. This didn't provide a good experience and left the popup open once the search started. Ensure the popup is always shown when using the keyboard and don't trigger the search until the popup is closed.
Differential Revision: https://phabricator.services.mozilla.com/D12324
--HG--
extra : moz-landing-system : lando
This is the first part of hiding the implementation of nsIJSID behind the
interface added in Part 1, such that we can substitute that implementation out.
I had to make a couple of changes to fix the errors caused by the new behaviour
in GenerateQI.
Differential Revision: https://phabricator.services.mozilla.com/D2279
Change the `<engine>.<alias>.urlbar` `SEARCH_COUNTS` keys to `<engine>.alias` as described in bug 1499193 comment 23 and later.
Differential Revision: https://phabricator.services.mozilla.com/D12038
--HG--
extra : moz-landing-system : lando
Since temporary permissions are only stored in the front-end side, we can't know whether we have
allowed page to autoplay or not without sending a request. Therefore, we want to notify the back-end
side when the temporary permissions changed.
Differential Revision: https://phabricator.services.mozilla.com/D7011
--HG--
extra : moz-landing-system : lando
Previous to bug 1453751 favicons were loaded from the network by a <xul:image>
tag with validate="never". This caused us to always use any cached version if
possible. Bug 1453751 used a normal load type causing us to revalidate with the
server for each request. This switches the loader to using the cache if possible.
Differential Revision: https://phabricator.services.mozilla.com/D11402
--HG--
extra : moz-landing-system : lando
Previous to bug 1453751 favicons were loaded from the network by a <xul:image>
tag with validate="never". This caused us to always use any cached version if
possible. Bug 1453751 used a normal load type causing us to revalidate with the
server for each request. This switches the loader to using the cache if possible.
Differential Revision: https://phabricator.services.mozilla.com/D11402
--HG--
extra : moz-landing-system : lando
As part of the conversion, support for notificationsHidden and children that are not notifications is also removed.
Differential Revision: https://phabricator.services.mozilla.com/D10894
--HG--
rename : toolkit/content/widgets/notification.xml => toolkit/content/widgets/notificationbox.js
extra : rebase_source : 36a5412e1e9a9dc591fd486d1123c1f763a6f173
* If a search is performed in a private window and the new pref `browser.engagement.search_counts.pbm` is true, then do not record `SEARCH_COUNTS` telemetry. Note that the the pref must be true. If it's false or doesn't exist, then we record telemetry even in pbm like we normally do currently. (We record `SEARCH_COUNTS` telemetry in two places: (1) In BrowserUsageTelemetry.jsm, and (2) "in-content" telemetry directly in the search service. So skip both of those places.)
* Also skip the other ancillary telemetry recorded by `BrowserUsageTelemetry._recordSearch`: a keyed scalar and a telemetry event.
* I made some modifications to the search service to let me test the "in-content" telemetry keys
Differential Revision: https://phabricator.services.mozilla.com/D10851
--HG--
extra : moz-landing-system : lando
Modify `BrowserUsageTelemetry.recordSearch` to take an alias instead of the bool `isAlias`. If an alias is given and it's an internal alias of the given engine, then increment a new `"engineName.@engine.source"` key under the `SEARCH_COUNTS` histogram -- in addition to incrementing the usual `"engineName.source"` key under that same histogram.
Differential Revision: https://phabricator.services.mozilla.com/D10633
--HG--
extra : moz-landing-system : lando
Now that we have moved some about: pages to the privileged content process,
opening these URLs from a non-privileged content process will trigger SessionStore
to restore the tab state due to a process flip. We will set favicons for these
URLs earlier to avoid flickering and improve perceived performance.
This patch also prevents the spinner whenever a page with a local about: URI
(about:blank and about: pages that resolve to jar:// or file:// URIs) is
loaded from a process that the URI cannot load in (e.g. loading about:newtab
in the web content process), as well as during tab duplication or session
restoration for such local about: URIs.
Before this patch, there were additional frames when opening a new window, causing
browser/base/content/test/performance/browser_windowopen.js to fail. This patch
will reduce the number of frames when opening a new window.
MozReview-Commit-ID: yjj2964KSz
--HG--
extra : source : cecc2d52e72e7c6e61137a9147735cb07a079d51
extra : intermediate-source : 21a6f1a83c73ce4fff654d4b2118e98375f0a528
extra : histedit_source : e8b8132856b7ee27b530798c2721b76118de655e
