Rather than playing whack-a-mole to proactively account for all the places where the menu might show up, let's just make sure its messages are always available.
Differential Revision: https://phabricator.services.mozilla.com/D200156
This includes a containers.json version increment and the necessary migration,
as the StringBundle identifiers are replaced with a Fluent reference.
As it's not possible to filter the attributes that are applied with DOM localization,
the code in utilityOverlay.js is a little clumsy. The non-acceskey versions are needed
due to bug 1297738, i.e. the long-press menu available from the tab bar down arrow.
Previously, the "Manage containers" menu item and its accesskey were defined in two places.
These are here combined into one.
Differential Revision: https://phabricator.services.mozilla.com/D194510
This allows us to deprecate `mozInputSource` for the Web while
avoiding console warnings for internal uses, which now use the
ChromeOnly `inputSource` attribute.
Differential Revision: https://phabricator.services.mozilla.com/D183643
This patch adds a new help menu item to link out to the device migration page on SUMO. I implemented this assuming we want this to be visible in 114 by default but hideable via a pref if needed - happy to flip this logic if we think it's safer to hide the menu item by default instead.
Differential Revision: https://phabricator.services.mozilla.com/D176180
Experimentation confirmed years ago that about:welcome shoudln't be treated as blank for urlbar focus, and no need for additional experimentation. Also fix a bug where about:welcome was treated as a blank/empty page resulting in about:preferences incorrectly replacing it.
Differential Revision: https://phabricator.services.mozilla.com/D174940
'fromChrome' really meant "force tabs to open in the foreground", so let's
rename it accordingly.
This removes the attempt to document arguments for openUILinkIn.
I'll add documentation back on the end of this stack, for openLinkIn, when
various bits are reorganized anyway.
Differential Revision: https://phabricator.services.mozilla.com/D170384
openLinkIn would really benefit from being split up a bit, and adding more
globals to the browser window is icky. Also, the story for opening new tabs if
you're not inside a window is a nightmare right now. Moving this code
to a module is a first step to making that story nicer.
I kept wrappers for all the functions I'm moving, and added the `window` as the
first argument. In the future we can update these functions to support being
called without a `window` ref. The one exception is getTopWin, where I updated
the callers in this patch.
I had to tweak the parameter detection of the different arguments supported by
openUILinkIn because forwarding calls means arguments.length is always larger
than 3... but then also removed it in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D170210
'fromChrome' really meant "force tabs to open in the foreground", so let's
rename it accordingly.
This removes the attempt to document arguments for openUILinkIn.
I'll add documentation back on the end of this stack, for openLinkIn, when
various bits are reorganized anyway.
Depends on D170210
Differential Revision: https://phabricator.services.mozilla.com/D170384
openLinkIn would really benefit from being split up a bit, and adding more
globals to the browser window is icky. Also, the story for opening new tabs if
you're not inside a window is a nightmare right now. Moving this code
to a module is a first step to making that story nicer.
I kept wrappers for all the functions I'm moving, and added the `window` as the
first argument. In the future we can update these functions to support being
called without a `window` ref. The one exception is getTopWin, where I updated
the callers in this patch.
I had to tweak the parameter detection of the different arguments supported by
openUILinkIn because forwarding calls means arguments.length is always larger
than 3... but then also removed it in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D170210
This also updates layoutdebug.js, which in some ways pretends to be like a browser window but
is its own special snowflake. I kept the method naming conventions similar to the main
browser window.
Depends on D168394
Differential Revision: https://phabricator.services.mozilla.com/D168395
This also updates layoutdebug.js, which in some ways pretends to be like a browser window but
is its own special snowflake. I kept the method naming conventions similar to the main
browser window.
Depends on D168394
Differential Revision: https://phabricator.services.mozilla.com/D168395
This patch replaces the previous ContractID-based lookup system for protocol
handlers, and replaces it with a new custom system in nsIOService. It will be
pre-populated with non-overridable static protocol handlers using the
StaticComponents infrastructure added in the previous part, and callers can
also dynamically register new protocol handlers at runtime.
This new system is intended to provide access to the default port and
non-dynamic protocol flags off-main-thread, by requiring these values to be
provided up-front as constants, rather than getting them from the xpcom
interface. The data is then guarded by an RWLock.
Callers which look up specific handlers by their contractID are not changed, as
the contract IDs for existing handlers have not been changed, so the lookup
will still succeed.
This change as-implemented breaks the nsGIOProtocolHandler on Linux, as it
removes the special code which would try to use that handler for some
protocols. This will be fixed in a later part by making the
nsGIOProtocolHandler use the dynamic registration APIs to register and
un-register protocol handlers at runtime in response to the GIO pref.
Differential Revision: https://phabricator.services.mozilla.com/D162804
This patch replaces the previous ContractID-based lookup system for protocol
handlers, and replaces it with a new custom system in nsIOService. It will be
pre-populated with non-overridable static protocol handlers using the
StaticComponents infrastructure added in the previous part, and callers can
also dynamically register new protocol handlers at runtime.
This new system is intended to provide access to the default port and
non-dynamic protocol flags off-main-thread, by requiring these values to be
provided up-front as constants, rather than getting them from the xpcom
interface. The data is then guarded by an RWLock.
Callers which look up specific handlers by their contractID are not changed, as
the contract IDs for existing handlers have not been changed, so the lookup
will still succeed.
This change as-implemented breaks the nsGIOProtocolHandler on Linux, as it
removes the special code which would try to use that handler for some
protocols. This will be fixed in a later part by making the
nsGIOProtocolHandler use the dynamic registration APIs to register and
un-register protocol handlers at runtime in response to the GIO pref.
Differential Revision: https://phabricator.services.mozilla.com/D162804
Propagate the ability to pass triggeringRemoteType through the desktop frontend
in various places, such that it is set when using the context menu or content
click handler.
Differential Revision: https://phabricator.services.mozilla.com/D161834
