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
