This patch rolls up all the required changes for this purpose. Since the
whole crash reporting flow must understand the new format it's not possible
to land this as separate patches as individually they would be broken. This
patch includes the following changes:
* Changes to the crash reporting machinery to write out annotations as JSON,
these includes changes to the DLL blocklist code that must be run at crash
time.
* Modifications to the crash reporter client so that it can read and
submit the new format; this includes platform-specific changes to the
Breakpad libraries it uses for submitting crashes.
* Modifications to the minidump-analyzer to understand and process the new
format correctly.
* Modifications to the crash manager to understand and process the new format
correctly.
* Modifications to GeckoView's crash handler to understand and submit the
new format correctly.
* Added new tests to cover the new format and modified existing ones to
accomodate the new one.
Differential Revision: https://phabricator.services.mozilla.com/D46848
--HG--
extra : moz-landing-system : lando
This change will be the first of multiple changes to control permissions in FxR on PC. This change introduces a new class, FxrPermissionPromptPrototype, in the FxR front end code. With the introduction of this class, all permission requests are denied by default. Subsequent changes will provide UI to give user control.
Differential Revision: https://phabricator.services.mozilla.com/D52283
--HG--
extra : moz-landing-system : lando
document.getAnonymousElementByAttribute is dead code now, and even when it wasn't this would
have returned null ever since <toolbarbutton> stopped using XBL.
Differential Revision: https://phabricator.services.mozilla.com/D51727
--HG--
extra : moz-landing-system : lando
_parseActionUrl was necessary for pre-QuantumBar code, because we were going
through the toolkit autocomplete component. Telemetry has been moved to the
UrlbarController, WebNavigation has a new hook to the QuantumBar, and the
autocomplete widget is no more used. Thus all this code can go.
Differential Revision: https://phabricator.services.mozilla.com/D50916
--HG--
extra : moz-landing-system : lando
This reverts part of bug 1576158, so that all current and future in-content pages share the same implementation.
Differential Revision: https://phabricator.services.mozilla.com/D49559
--HG--
extra : moz-landing-system : lando
While the availability of Reader View is somewhat noticeable visually, a screen reader user won't be aware of this unless they explicitly explore the toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D48036
--HG--
extra : moz-landing-system : lando
This reverts bug 1425541.
This was intended to make it easy for accessibility clients to retrieve the Reader View state programmatically.
However, it was never actually used by any clients.
Differential Revision: https://phabricator.services.mozilla.com/D48035
--HG--
extra : moz-landing-system : lando
This just pulls chunks of TelemetryStopwatch and similar code,
which often eats up several lines, into some helper functions.
This should just help reduce the cognitive load of reading this
code.
Depends on D47349
Differential Revision: https://phabricator.services.mozilla.com/D47350
--HG--
extra : moz-landing-system : lando
This way we ensure that the reentrancy guard always stays in effect.
It should just be a little easier to reason about everything if it's
all channeled through the same place.
Differential Revision: https://phabricator.services.mozilla.com/D47349
--HG--
extra : moz-landing-system : lando
It's useless if the tab is already visible (i.e., has renderLayers=true), per
the previous patches, and that's the only point at which it gets called.
Differential Revision: https://phabricator.services.mozilla.com/D47131
--HG--
extra : moz-landing-system : lando
Adds a new event listener to `browser.urlbar` called `onResultPicked`. This event is fired for tip results when they don't specify a URL. Hypothetically it could be fired for any type of result that didn't specify a URL, but that's only tips for now.
The listener is passed two arguments: the payload of the result that was picked, and a "details" object whose properties depend on the type of result. For tips, details is `{ helpPicked }`, where `helpPicked` is true if the help button was picked and false if the main button was picked.
Differential Revision: https://phabricator.services.mozilla.com/D46254
--HG--
extra : moz-landing-system : lando
Re-enable skipped webRTC tests on Mac which were disabled due to the macOS 10.14 permission prompts causing timeouts.
Don't trigger OS camera and microphone permission prompts for fake devices (used for tests).
Differential Revision: https://phabricator.services.mozilla.com/D46893
--HG--
extra : moz-landing-system : lando
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
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
In bug 1519577, the badged-button class for toolbarbuttons was replaced
with a "badged" attribute but a few old uses of the class were overlooked.
This patch fixes them.
Differential Revision: https://phabricator.services.mozilla.com/D34438
--HG--
extra : moz-landing-system : lando
Daniel Varga
Moritz Birghan
Ehsan Akhgari
Razvan Maries
Gabriele Svelto
Brian Grinstead
Andreea Pavel
thomasmo
Dorel Luca
Neil Deakin
Cosmin Sabou
Noemi Erli
Carson Greene
Scott
Coroiu Cristina
Erica Wright
Anny Gakhokidze
Marco Bonardo
Arthur Iakab
Shane Caraveo
Harry Twyford
Mark Banner
Sean Feng
Oana Pop Rus
Mike de Boer
Jan-Ivar Bruaroey
James Teh
Sebastian Hengst
Gijs Kruitbosch
Tom Tung
Michael Kaply
Doug Thayer
Emilio Cobos Álvarez
Ed Lee
Olli Pettay
Drew Willcoxon
Sebastian Streich
Haik Aftandilian
Paul Zuehlcke
Kris Maglione
Rob Wu
Johann Hofmann
Bogdan Tara
Mihai Alexandru Michis
monikamaheshwari
Andreas Farre
Abdoulaye O. Ly
Ciure Andrei
Brindusan Cristian
Jared Wein
Mike Conley
Csoregi Natalia
Boris Zbarsky
Sylvestre Ledru
Jonathan Kingston
Victor Porof
Andrew Swan
Geoff Lankow
Dale Harvey
Nihanth Subramanya