There is still another related bug 1579591, which this may make a bit less likely, since that seems to be timing dependent, but
the patch is not trying to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D46242
--HG--
extra : moz-landing-system : lando
This is done to offset the requirement that extensions have to get persistent permission before
they can start using WebRTC in popups.
Differential Revision: https://phabricator.services.mozilla.com/D45335
--HG--
extra : moz-landing-system : lando
The goal is to
- Avoid showing any permission prompt when calling getUserMedia in webextension popups,
while still checking for persistent permissions.
- Never allow getUserMedia calls on background pages.
Differential Revision: https://phabricator.services.mozilla.com/D45333
--HG--
extra : moz-landing-system : lando
This is done to offset the requirement that extensions have to get persistent permission before
they can start using WebRTC in popups.
Differential Revision: https://phabricator.services.mozilla.com/D45335
--HG--
extra : moz-landing-system : lando
The goal is to
- Avoid showing any permission prompt when calling getUserMedia in webextension popups,
while still checking for persistent permissions.
- Never allow getUserMedia calls on background pages.
Differential Revision: https://phabricator.services.mozilla.com/D45333
--HG--
extra : moz-landing-system : lando
This is done to offset the requirement that extensions have to get persistent permission before
they can start using WebRTC in popups.
Differential Revision: https://phabricator.services.mozilla.com/D45335
--HG--
extra : moz-landing-system : lando
The goal is to
- Avoid showing any permission prompt when calling getUserMedia in webextension popups,
while still checking for persistent permissions.
- Never allow getUserMedia calls on background pages.
Differential Revision: https://phabricator.services.mozilla.com/D45333
--HG--
extra : moz-landing-system : lando
I haven't been able to work out a reason why we should show the
spinner before this.loadTimer is cleared. All this does is allow
for random reordering of events to sometimes show a spinner early.
This should ideally just make the spinner logic more rubust to
event ordering changes, without sacrificing visibility into tab
switch timings.
Differential Revision: https://phabricator.services.mozilla.com/D44878
--HG--
extra : moz-landing-system : lando
This just adds a bit of information to the AsyncTabSwitcher's
logging and cleans up the display to make it quicker to find
what changed, especially with large numbers of tabs. The bit of
new information that I'm particularly interested in is what
event triggered a particular update - so now every time we call
postActions, we include the name of the event.
Differential Revision: https://phabricator.services.mozilla.com/D44710
--HG--
extra : moz-landing-system : lando
The idea here is that we avoid updating all site data in SiteDataManager.jsm
just for checking a single host/origin and that we optimize performance by prioritizing
the most common data type (cookies) and synchronous lookups (AppCache) and returning
early if any data was found.
We will still refresh the site data list for clearing once the user clicks on "Clear Site Data".
Differential Revision: https://phabricator.services.mozilla.com/D42800
--HG--
extra : moz-landing-system : lando
This will allow these heuristics to be used on mobile.
This depends on GeckoView supporting a JavaScript module
at resource:///modules/BrowserUsageTelemetry.jsm with the
interface described in nsIBrowserUsage.idl. Bug 1573238 has
been filed in order to implement this module on GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D41621
--HG--
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
With the current code, if any event handler throws, `_processing` remains
true, and every subsequent event goes into an infinite loop dispatching 0ms
timeouts to run on the next tick.
Differential Revision: https://phabricator.services.mozilla.com/D39931
--HG--
extra : moz-landing-system : lando
This is based on D39589, which moves the top sites API from toolkit to browser.
* Add a `newtab` option to `browser.urlbar.topSites.get` (similar to the abandoned D36200) that returns exactly the top sites shown on newtab
* Add a `AboutNewTab.getTopSites` function that returns those sites from activity stream
* Keep the changes made in bug 1547669
There are a couple of missing things related to the default top sites that this doesn't address but ideally we would have. I think we can come back to these if necessary.
* Actual favicons for the default top sites instead of using the bigger tile images since they don't seem to be the same for every site.
* Proper names names for the default sites. There's a `hostname` property, but it would be nice to have e.g. "YouTube" instead of "youtube".
Differential Revision: https://phabricator.services.mozilla.com/D39591
--HG--
extra : moz-landing-system : lando