And cleanup similar code in nsXULTooltipListener. That code shouldn't
need to deal with zoom since the target and the tooltip are in the same
document.
Differential Revision: https://phabricator.services.mozilla.com/D139235
"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
