"Send Video to Device" feature is gone in desktop and mobile, and also,
we removed Presentation API implementation, so this is unnecessary now.
Differential Revision: https://phabricator.services.mozilla.com/D132330
This commit does a couple of things:
- move whereToOpenLink and getRootEvent implementations into BrowserUtils,
so they can be used from the child process.
- forward callers in utilityOverlay.js to the BrowserUtils ones
(bug 1742889 will get rid of the forwarding and update all the callers;
we might be able to get this and bug 1739929 into beta if risk is low
enough, and touching a bunch of extra files really doesn't help with
that)
- move the lazy-load of BrowserUtils from browser.js to utilityOverlay.js
This is safe because everywhere that loads browser.js also loads
utilityOverlay.js. It's needed because there are some places that use
utilityOverlay.js but not browser.js, and so now they need access to
BrowserUtils.jsm.
- use whereToOpenLink to determine if we should avoid consuming the transient
user gesture activation in the child click handling code.
- add an automated test based on the testcase in the bug.
When working on this, I initially put the check using whereToOpenLink in
the toplevel of the function, and then when I ran places test to check that
I hadn't broken any places consumers of whereToOpenLink or getRootEvent,
realized that I had broken `browser_markPageAsFollowedLink.js`, because it
relies on "normal" (ie no modifier key, left button) link clicks making it
to ClickHandlerParent.jsm . I filed bug 1742894 about this. I've not tried
to fix that here, instead I've tried to ensure that paths through this
function are as untouched as possible while still fixing bug 1739929 and
bug 1742801.
Differential Revision: https://phabricator.services.mozilla.com/D132102
It might fire before styles are invalidated, so it might cache the wrong
styles.
Instead, fire an event on the window once everything in that window has
been invalidated, not just the global theme.
This is causing failures with the patch in bug 1740089, since after that
patch `browser_ext_browserAction_theme_icons` trigger the theme changes
when switching from dark to default mode or similar.
Differential Revision: https://phabricator.services.mozilla.com/D131396
This does a couple of things:
* Instead of using the `not_now` telemetry event object for the cases where the
dialog is closed by the Escape key or some other atypical way, reserve
`not_now` -- renamed `not_now_link` -- specifically for clicks on the "Not
now" link and add two new objects: `dismissed_escape_key` and
`dismissed_other`. That should give us a little better understanding of how
the dialog is being dismissed. The new `not_now_link` name is to avoid
conflation with the previous meaning of `not_now`.
* Add a new `browser.urlbar.quicksuggest.onboardingDialogChoice` pref that
stores exactly the same values as the telemetry event. e.g., if the dialog is
accepted, then we'll record a telemetry event whose object is `accept` and
we'll also store `accept` in the pref.
I figure if we decide to show the onboarding again for people who have already
seen it, (1) we'll use this pref to decide the flow for any given user, and (2)
we'll need to add another pref for the user's response to the "v2" dialog, or
maybe we could morph this one into an array of responses or something more
complex like that.
Differential Revision: https://phabricator.services.mozilla.com/D127354
This load was causing a process switch after the changes in this patch.
This caused the view-source load to also process-switch back when loaded
and confused some view-source machinery. The load isn't necessary, and
if skipped the process switch due to navigation will not occur.
Differential Revision: https://phabricator.services.mozilla.com/D120736
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
The bug was that the tooltip was only being shown for reader-mode-button-icon. The tooltip would show if you hovered right over the icon, and it would be undefined otherwise. This patch shows the tooltip regardless of the hover target. The other items on nodeToTooltipMap and nodeToShortcutMap are toolbarbuttons, so their icons are added in CSS and event handling always sees the parent node as the hover target. The reader mode button icon, however, is an <image> child of its parent. Either it or its parent could be hover targets. I considered added some handling in GetDynamicShortcutTooltipText along the lines of checking node.closest(reader-mode-button). I settled on just adding more entries to nodeToTooltipMap and nodeToShortcutMap since it's safer and easier to uplift.
Differential Revision: https://phabricator.services.mozilla.com/D122126
This load was causing a process switch after the changes in this patch.
This caused the view-source load to also process-switch back when loaded
and confused some view-source machinery. The load isn't necessary, and
if skipped the process switch due to navigation will not occur.
Differential Revision: https://phabricator.services.mozilla.com/D120736
After the changes in this bug, about:blank loads triggered by chrome will
finish in a "web" content process, as they have an untrusted null principal
without a precursor. In a few places throughout the codebase, however, we
perform about:blank loads with the explicit expectation that they do not change
processes. This new remoteTypeOverride option allows the intended final process
to be explicitly specified in this situation.
For security & simplicity reasons, this new attribute is limited to only be
usable on system-principal triggered loads of about:blank in toplevel browsing
contexts.
Differential Revision: https://phabricator.services.mozilla.com/D120671
