We disabled Backspace as a keyboard shortcut to go back one page (bug 1041377). We can use the Back and Forward buttons' tooltips to advertise the other shortcuts users can use instead of Backspace (like we do on the Reload button's tooltip).
Differential Revision: https://phabricator.services.mozilla.com/D102053
We disabled Backspace as a keyboard shortcut to go back one page (bug 1041377). We can use the Back and Forward buttons' tooltips to advertise the other shortcuts users can use instead of Backspace (like we do on the Reload button's tooltip).
Differential Revision: https://phabricator.services.mozilla.com/D102053
This patch makes the contentAreaUtils.saveURL to be aware of the
cookieJarSettings, and updates all callers.
This also updates the documentation of the persistArgs
'cookieJarSettings' for internalPersist().
Differential Revision: https://phabricator.services.mozilla.com/D98455
This patch makes the ContextMenu to send cookieJarSettings from content
to the parent process via ContextMenuChild/Parent. The cookieJarSettings
will be used in 'Save ... As'.
Differential Revision: https://phabricator.services.mozilla.com/D95615
This patch makes the ContextMenu to send cookieJarSettings from content
to the parent process via ContextMenuChild/Parent. The cookieJarSettings
will be used in 'Save ... As'.
Differential Revision: https://phabricator.services.mozilla.com/D95615
This is a band-aid for now, because I don't know how to best deal with
it.
Probably we should just print the plaintext selection contents,
unstyled, though that's a totally different codepath than what we do for
regular document selection, so probably deserves its own bug. Meanwhile,
this should prevent easy printing failures.
View-selection-source also doesn't deal with it properly so do the same
there too for now.
Differential Revision: https://phabricator.services.mozilla.com/D94595
In order to avoid over/under-counting, we need to treat window.print()
specially. The new UI was using aOpenWindowInfo.isForPrintPreview for
that, but that doesn't quite work for the old UI (because it will
trigger a regular print, not a preview).
But since isForPrintPreview was only really needed to distinguish
window.print(), just rename it and set it to true when the old UI is
triggered by window.print() as well.
Differential Revision: https://phabricator.services.mozilla.com/D92925
This allows to use the feature from the context menu and is very
straight-forward.
This has the benefit of working with fission (as print from the focused
frame) and so on.
Making a checkbox on the UI on top of this is doable, but it is a lot
more complex (requires a bunch of both front-end and platform work)
because undoing this implies restoring the DOM which "print selection"
removes.
I think the context menu entry is very useful regardless of whether we
add a checkbox to undo it, and other browsers (with smaller context
menus) seem to agree.
Differential Revision: https://phabricator.services.mozilla.com/D92205
This also moves gInitialised into SearchService, as it no longer needs to be separate, and it makes changing it for tests easier.
Depends on D88462
Differential Revision: https://phabricator.services.mozilla.com/D88622
Having the fill logins context menu on PDF forms could lead to users
accidentally entering their login information into to a PDF form which
is probably not a desired or expected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D88198
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
* 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
This introduces a new toolkit module, ContentDOMReference, which can generate identifiers
for DOM elements that can be safely passed across the process boundary without having to
use the CPOW infrastructure.
The Password Manager code seemed to be the only thing using the original CPOW, so this
has been updated to use the ContentDOMReference identifier instead.
Differential Revision: https://phabricator.services.mozilla.com/D32758
--HG--
extra : moz-landing-system : lando
This introduces a new toolkit module, ContentDOMReference, which can generate identifiers
for DOM elements that can be safely passed across the process boundary without having to
use the CPOW infrastructure.
The Password Manager code seemed to be the only thing using the original CPOW, so this
has been updated to use the ContentDOMReference identifier instead.
Differential Revision: https://phabricator.services.mozilla.com/D32758
--HG--
extra : moz-landing-system : lando
This introduces a new toolkit module, ContentDOMReference, which can generate identifiers
for DOM elements that can be safely passed across the process boundary without having to
use the CPOW infrastructure.
The Password Manager code seemed to be the only thing using the original CPOW, so this
has been updated to use the ContentDOMReference identifier instead.
Differential Revision: https://phabricator.services.mozilla.com/D32758
--HG--
extra : moz-landing-system : lando
Also, in many place, we use document uri as referrer. It is not right
for the case srdoc iframe. We should use the last non-srdoc parent
document's uri
Differential Revision: https://phabricator.services.mozilla.com/D30191
--HG--
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-data.html
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-srcdoc.html
extra : moz-landing-system : lando
* Remove the PWMGR_MANAGE_OPENED histogram and references to it
* Add a new pwmgr event category, open_management method and objects for each of the entry points
* Expect an entryPoint key to be passed to LoginHelper.openPasswordManager so it can record the event
* Update all callers of LoginHelper.openPasswordManager to pass the correct entryPoint key
* Record the event in preferences when we open the password management UI as a subdialog
* Add test assertions to confirm the telemetry events are recorded, piggybacking on existing tests where practical to avoid duplicating helpers and boilerplate
Differential Revision: https://phabricator.services.mozilla.com/D29840
--HG--
extra : moz-landing-system : lando
For videos that break after alreading being in Picture-in-Picture, we keep the toggle enabled so
that the user can exit Picture-in-Picture.
Differential Revision: https://phabricator.services.mozilla.com/D27951
--HG--
extra : moz-landing-system : lando
For videos that break after alreading being in Picture-in-Picture, we keep the toggle enabled so
that the user can exit Picture-in-Picture.
Differential Revision: https://phabricator.services.mozilla.com/D27951
--HG--
extra : moz-landing-system : lando
Replaced new Function() by CustomEvent carrying original click event as sourceEvent.
Adapted all oncommand listeners to use event.sourceEvent instead of event.
Differential Revision: https://phabricator.services.mozilla.com/D18847
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
This patch removes "Inspect Element" menu item from content context menu in
case that about:devtools-toolbox are opening.
However, we may be able to remove after fixing 1515265.
Depends on D16684
Differential Revision: https://phabricator.services.mozilla.com/D16685
--HG--
extra : moz-landing-system : lando
This patch removes "Inspect Element" menu item from content context menu in
case that about:devtools-toolbox are opening.
However, we may be able to remove after fixing 1515265.
Depends on D16684
Differential Revision: https://phabricator.services.mozilla.com/D16685
--HG--
extra : moz-landing-system : lando
This patch removes "Inspect Element" menu item from content context menu in
case that about:devtools-toolbox are opening.
However, we may be able to remove after fixing 1515265.
Depends on D16684
Differential Revision: https://phabricator.services.mozilla.com/D16685
--HG--
extra : moz-landing-system : lando
nsIBrowserSearchService::currentEngine and nsIBrowserSearchService::defaultEngine are the same thing.
The use of defaultEngine makes more sense and thus we are phasing out the use of currentEngine and replace it with defaultEngine.
Differential Revision: https://phabricator.services.mozilla.com/D7972
--HG--
extra : moz-landing-system : lando
nsIBrowserSearchService::currentEngine and nsIBrowserSearchService::defaultEngine are the same thing.
The use of defaultEngine makes more sense and thus we are phasing out the use of currentEngine and replace it with defaultEngine.
Differential Revision: https://phabricator.services.mozilla.com/D7972
--HG--
extra : moz-landing-system : lando
- Support viewTypes property in menus.create / menus.update.
- Add info.viewType to menus.onShown / menus.onClicked event.
- This "viewType" reuses the existing extension.ViewType enum,
which is a "tab", "popup" (pageAction/browserAction) or "sidebar".
Differential Revision: https://phabricator.services.mozilla.com/D6205
--HG--
extra : moz-landing-system : lando
The new method allows extensions to modify menu items in their own
moz-extension:-pages, with the following features:
- All matching extension items are shown in the root menu (instead of
being moved into a submenu), above other menu items, if any.
- The icons for these menu items are customizable.
- Optionally, the default menu items (including those from other
extensions) can be hidden.
Depends on D6621
Differential Revision: https://phabricator.services.mozilla.com/D6622
--HG--
extra : moz-landing-system : lando
