The pseudo-class and nsContextMenu context attribute were using reveal,
the pseudo-element and webidl attribute were using "show".
Use reveal consistently and update the accesskey so that there aren't
conflicts with existing commands. Also enable the feature in
browser_contextmenu_input.js so that this change is tested.
Differential Revision: https://phabricator.services.mozilla.com/D136086
Instead of relying on untrusted click/auxclick events anywhere
instantiating the actor, and then having to look for links, after this
patch we'll only instantiate the actor for actual link clicks. This
patch moves to using a chrome-only command event (with type
`chromelinkclick`) dispatched from the link click post-visitor
to accomplish that.
In future we should probably move both this and the
middle-click-to-paste handling into DOM code (or, for the latter,
remove it) but this is a less invasive solution.
This also moves the middle-click-to-paste handling into its own
listener. It needs to listen to page events in general (not just
links) but is disabled everywhere by default, so registering an
actor for everyone doesn't seem like a good trade-off. To avoid
duplicating all the logic (we do need to avoid doing middle-click
navigation based on the clipboard when clicking on links!), as
well as keeping patch size down, the actual control flow goes
through the click handler actor still.
Differential Revision: https://phabricator.services.mozilla.com/D134011
Instead of relying on untrusted click/auxclick events anywhere
instantiating the actor, and then having to look for links, after this
patch we'll only instantiate the actor for actual link clicks. This
patch moves to using a chrome-only command event (with type
`chromelinkclick`) dispatched from the link click post-visitor
to accomplish that.
In future we should probably move both this and the
middle-click-to-paste handling into DOM code (or, for the latter,
remove it) but this is a less invasive solution.
This also moves the middle-click-to-paste handling into its own
listener. It needs to listen to page events in general (not just
links) but is disabled everywhere by default, so registering an
actor for everyone doesn't seem like a good trade-off. To avoid
duplicating all the logic (we do need to avoid doing middle-click
navigation based on the clipboard when clicking on links!), as
well as keeping patch size down, the actual control flow goes
through the click handler actor still.
Differential Revision: https://phabricator.services.mozilla.com/D134011
I've erred on the side of removing code here. I think that I got most of it,
but there was quite a bit of accrued code.
Thanks to Gijs for fluent fixups (and code cleanup). This retains some notice
of the failed version.
Bug 1586846, Bug 1579285, Bug 1586846, and Bug 1617275 all added code here.
Differential Revision: https://phabricator.services.mozilla.com/D133591
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
* Add jswindowactors for the Screenshots component, to facilitate communication between the UI (lives in the parent) and the content document.
* Fetch content document dimensions/offsets with e.g: `ScreenshotsUtils.fetchContentBounds(gBrowser.selectedBrowser)`.
Differential Revision: https://phabricator.services.mozilla.com/D129326