* Remove usernameField from getFieldContext since it isn't used if we return the state of the specified field. Then we don't need the hacky override for usernameField depending on hasBeenTypePassword.
* Return early in LMP._onPasswordEditedOrGenerated if the tab closes to address a test failure in browser_context_menu.js.
Differential Revision: https://phabricator.services.mozilla.com/D69314
--HG--
extra : moz-landing-system : lando
Only 3 callers are using a non-UTF-8 charset as the first parameter.
* MediaDocument.cpp: This does not make sense because the "filename" part of
URLs will always be encoded with UTF-8.
* nsContextMenu.js: This is wrong because "mailto:" URLs don't care about the
document charset.
* Finder.jsm: This caused bug 1623222.
Differential Revision: https://phabricator.services.mozilla.com/D67386
--HG--
extra : moz-landing-system : lando
This aligns with the behaviour before bug 1595915 since password generation was nested under the disabled "Fill (username|password)" option.
Differential Revision: https://phabricator.services.mozilla.com/D64405
--HG--
extra : moz-landing-system : lando
Instead of updating the Bookmark This Page / Edit Bookmark menuteitems on popupshowing,
update them when the star button is suppposed to change. This better supports MacOS behavior
where the native menubar can't be updated after being shown, and avoids many callpoints in
favor of just a few.
Differential Revision: https://phabricator.services.mozilla.com/D64399
--HG--
extra : moz-landing-system : lando
This aligns with the behaviour before bug 1595915 since password generation was nested under the disabled "Fill (username|password)" option.
Differential Revision: https://phabricator.services.mozilla.com/D64405
--HG--
extra : moz-landing-system : lando
Given that the "View Background Image" option never makes sense in the PDF Viewer, it's simply always removed from the context menu.
Differential Revision: https://phabricator.services.mozilla.com/D52599
--HG--
extra : moz-landing-system : lando
* Inform users in autocomplete that using a generated password will cause it to be automatically saved.
* Don't fill generated passwords from the context menu directly, that menu item (renamed) should simply force the generation UI to appear in autocomplete.
Differential Revision: https://phabricator.services.mozilla.com/D54338
--HG--
extra : moz-landing-system : lando
Depends on D49941
Using ContentDOMReference instead of creating an array of selectors makes inspect element more stable in case the page is modified between after the contextmenu opens.
It will also make the feature easier to make fission compatible
Differential Revision: https://phabricator.services.mozilla.com/D49303
--HG--
extra : moz-landing-system : lando
* Skip showing the password manager items in the context menu from an about: page
Differential Revision: https://phabricator.services.mozilla.com/D42963
--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
