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
At a high level, this change does the following:
- move the pluginchild actor to be a JSWindowActorChild
- move the parent handling from browser-plugins into a JSWindowActorParent
- move the crash handling from ContentCrashHandlers.jsm to the parent actor,
using a `PluginManager` object. It needs to talk to the actors (and vice
versa), so this seemed a better fit than spreading actor implementation
details to other JSMs.
- switch to using plugin IDs to identify plugins cross-process, instead of
combinations of names or other properties of the plugin tag. As part of that,
ensured plugin IDs are unique between "fake" plugins and the other ones.
- drop support for having a notification for more than 1 plugin. We only support
Flash, in practice, so there didn't seem to be much point in the added
complexity of trying to support more than 1 thing.
Some notes:
- the previous implementation mixes runIDs (for NPAPI plugin process "runs")
and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee
these don't conflict, so I've split them out to avoid issues. There's a
pluginCrashID object I pass around instead that has either a runID or
pluginID. Happy to rename some more for clarity.
- the previous implementation used `pluginInfo` and `plugin` for a bunch of
different types of variables. I've tried to be consistent, where:
* `pluginElement` is a DOM element for a plugin
* `activationInfo` is a JS object used to track click to play state for a plugin
* `plugin` is a plugintag as returned by the pluginhost service
* `pluginCrashID` is an identifier for a crashed plugin (see previous point).
- I'm still using broadcastAsyncMessage to tell the content processes about
gmp plugin crashes and plugin crash submission updates, because there's no
guarantee the actors are instantiated (for gmp plugins) nor can the parent
easily find out which actors to talk to (for either gmp or npapi plugins).
Open to suggestions there, too. I think our best bet might be moving that to
IPDL-based IPC within the GMP code, but that feels like a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D37665
--HG--
rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm
extra : moz-landing-system : lando
My preference was to annotate most of the failing tests with `fail-if` so that
if they start passing, the `fail-if` needs to be removed and they need to keep
passing. That doesn't work for tests that timeout, or which trigger failures
from their cleanup functions, however, so those tests need skip-if. And tests
with fail in their cleanup functions likely leave the browser in an
inconsistent state for subsequent tests, anyway, so really should be skipped
regardless.
There are some remaining tests which still fail because of crashes. I chose
not to skip them here, but to fix the crashes in separate bugs instead.
Differential Revision: https://phabricator.services.mozilla.com/D38247
--HG--
extra : rebase_source : 39ba8fec2e882cfe577c5f2b58ab7e4b461f1178
A bunch of existing code assumes that <tab> elements are the immediate
and only children of a <tabs> element, and uses dom apis to traverse
relationships between these elements. To simplify conversion of <tabs>
to a custom element (and hopefully improve readability a bit at the same
time!), introduce new apis:
On <tab>
this.parentNode -> this.container
this.nextElementSibling -> this.container.findNextTab(...)
this.previousElementSibiling -> this.container.findNextTab(...)
On <tabs>
this.children -> this.allTabs
Differential Revision: https://phabricator.services.mozilla.com/D34648
--HG--
extra : source : f4e21e465f384b90fa1e768141c4db708748bf66
extra : histedit_source : 95d8a4242e8e04df9e29c2b647558d37e910b845
A bunch of existing code assumes that <tab> elements are the immediate
and only children of a <tabs> element, and uses dom apis to traverse
relationships between these elements. To simplify conversion of <tabs>
to a custom element (and hopefully improve readability a bit at the same
time!), introduce new apis:
On <tab>
this.parentNode -> this.container
this.nextElementSibling -> this.container.findNextTab(...)
this.previousElementSibiling -> this.container.findNextTab(...)
On <tabs>
this.children -> this.allTabs
Differential Revision: https://phabricator.services.mozilla.com/D34648
--HG--
extra : rebase_source : affeda0295a5195124709f322de524aea3a28a3f
Paul Zuehlcke
Abdoulaye O. Ly
Ciure Andrei
Moritz Birghan
Ehsan Akhgari
Brindusan Cristian
Jan-Ivar Bruaroey
Jared Wein
Bogdan Tara
Rob Wu
Mark Banner
Mike Conley
Michael Kaply
Kris Maglione
Drew Willcoxon
Csoregi Natalia
Boris Zbarsky
Gijs Kruitbosch
Sylvestre Ledru
Andreea Pavel
harry
Jonathan Kingston
Sean Feng
Victor Porof
Andrew Swan
Geoff Lankow
Dale Harvey
Erica Wright
Johann Hofmann