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
This patch fixes the CSS rule for displaying the disabled tracking
protection icon when TP is off.
Differential Revision: https://phabricator.services.mozilla.com/D38668
--HG--
extra : moz-landing-system : lando
This is just so that both the launcher process and other Gecko code can share
this method.
Differential Revision: https://phabricator.services.mozilla.com/D38943
--HG--
extra : moz-landing-system : lando
* Move AddressBar.rst into a new browser/components/urlbar/docs directory
* Break it up into several files, which makes the patch look way bigger than it really is because I used `hg cp` to preserve blame
* Add an Experiments & Extensions file/subsection, to be written later
* Rewrite the intro a little for wording and also to reflect the fact that quantumbar has shipped, and also tweak the wording of some subsection titles
Differential Revision: https://phabricator.services.mozilla.com/D38938
--HG--
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/contact.rst
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/debugging.rst
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/overview.rst
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/telemetry.rst
rename : browser/docs/AddressBar.rst => browser/components/urlbar/docs/utilities.rst
extra : moz-landing-system : lando
This patch adds a css rule to change the margin between glass icon
and the edge of url bar. This is needed since the tracking protection
icon won't be shown when search glass icon is shown.
Differential Revision: https://phabricator.services.mozilla.com/D38502
--HG--
extra : moz-landing-system : lando
This change adds functionality for the new command line argument, --fxr. This
will be used to create a new, separate browser window for Firefox Reality on
desktop.
Differential Revision: https://phabricator.services.mozilla.com/D37957
--HG--
extra : moz-landing-system : lando
This just changes the `TITLE_TAGS_SEPARATOR` to the non-printable character `\x1F`, the unit separator, which seems appropriate.
At first I thought we could use the result label to store tags since we're not using the label at all right now. Hacky, but better than storing them in the title. But (1) `nsAutoCompleteSimpleResult::GetLabelAt` falls back to the value if the label is empty, and (2) `nsAutoCompleteController::GetLabelAt` actually returns the same thing as `GetValueAt`, i.e., the value, not the label. It's doable, but we'd need set the label to some special value for every result that doesn't have tags so that the label doesn't fall back to the value so we can tell which results don't have tags, and we'd need to make sure to always directly ask results for labels instead of going through the controller. head_autocomplete.js goes through the controller, and I didn't check what else does too.
So then I thought we could store tags in the style with a special substring like "tags=tag1,tag2,tag3". Again it's doable, but:
The simplest fix is to just change the separator to an unprintable character. That should work, right? We can do better whenever we finally rewrite/refactor UnifiedComplete for quantumbar.
Differential Revision: https://phabricator.services.mozilla.com/D38790
--HG--
extra : moz-landing-system : lando
Narcis Beleuzu
Boris Zbarsky
Tim Nguyen
Gijs Kruitbosch
mcrawford@mozilla.com
Tim Huang
Aaron Klotz
Edwin Gao
Micah Tigley
Drew Willcoxon
Johann Hofmann
Ryan VanderMeulen
Cosmin Sabou
Daisuke Akatsuka
Erica Wright
Nathan Froyd
harry
Ciure Andrei
thomasmo
Shane Caraveo
Michael Kaply
Bogdan Tara
Eugen Sawin
Andreea Pavel
Andrei Oprea