[about:addons] No context menu opened when triggered in the inline options ui XUL browser

VERIFIED FIXED in Firefox 69

Status

()

defect
VERIFIED FIXED
Last month
12 days ago

People

(Reporter: rpl, Assigned: mconley)

Tracking

(Blocks 1 bug, Regression, {regression})

69 Branch
mozilla69
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox67 unaffected, firefox68 unaffected, firefox69 verified)

Details

Attachments

(2 attachments, 1 obsolete attachment)

In Firefox 69 triggering the context menu in the extensions options_ui embedded in about:addons doesn't open the context menu anymore.

The related tests defined in browser_ext_optionsPage_popups.js are still able to trigger the context menu (I'm pretty sure that the test is still working because it is currently triggering the event directly in the remote XUL browser, instead of BrowserTestUtils.synthesizeMouseAtCenter) and so we missed to notice the regression.

Bisecting the issue pointed to Bug 1505909, which makes sense given that in Bug 1505909 the context menu internals have been adapted to make them Fission-aware.

After digging a bit, it seems to me that the context menu is actually being triggered, but the event is being intercepted and handled by the ContextMenuChild instance related to the "about:addons" page that contains the options_ui browser XUL element, before the ContextMenuChild related to the options ui extension page had any chance to intercept and handle it.

e.g. right-clicking on a <a href="..."></a> DOM element part of an extension options page,
is intercepted and handled as an event targeting the options_ui browser XUL element, instead of the DOM element part of the extension options page.

To quickly double-check that this is actually the case, I briefly tried to make ContextMenuChild's handleEvent to early exit and not handling the event if the composedTarget is a XUL browser element embedded, and at that point the expected context menu has been triggered on the extension page's <a href="..."></a> DOM element.

Thanks for filing! Looking.

Flags: needinfo?(mconley)

Here is the test extension that I used to test the issue (and bisect it with mozregress)

The extension contains a simple HTML page with a link (on which I was right-clicking to trigger the context menu) used as an options page embedded in the about:addons details view (and also reused on the sidebar, browserAction popup and extension devtools panel).

Thanks, rpl. I'm able to reproduce now, and have a solution en route. Much appreciated!

Flags: needinfo?(mconley)
Assignee: nobody → mconley

This fixes Bug 1558506 by making it so that the parent process ignores the context menu event
when right-clicking on the remote <browser> hosting the Add-on Options page. Before, we were
handling the event, stopping it from propagating and preventDefault'ing it, and then sending
a message to the parent that ultimately did nothing (since we knew that we didn't want to
display the context menu). Stopping propagation and preventDefault'ing meant that the event
was never fired in the Extension process for the options page.

With the parent process now returning early in the event that it knows that it doesn't want
to be the one to open the context menu, the underlying ContextMenuSpecialProcessChild can
handle the contextmenu event in the extension process, and do the right thing.

Pushed by mconley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3876241cc1ec
Don't send a message for context menus when we know we don't want to open one. r=NeilDeakin

There are also dt failures on browser_aboutdebugging_devtoolstoolbox_contextmenu.js
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=251733835&repo=autoland&lineNumber=1782

Attachment #9071925 - Attachment is obsolete: true

In the content process case, preventing default stops the context menu event from being dispatched
within remote iframes, which is what causes bug 1558506.

In the parent process case, preventing default stops the nsXULPopupListener from opening the context
menu for us when we don't want ContextMenuParent to handle it, which we don't want to do.

Pushed by mconley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/053143993e49
Don't preventDefault the contextmenu event in ContextMenuChild.jsm. r=NeilDeakin
Status: NEW → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

Verified in Win7x64 and MacOS 10.14.1 using FF70.0a1 (20190710215049) and FF69.0b3 using the extension provided in comment 2.
I have installed the extension and have verified the context menu can be open when right clicking the link in both places it is displayed (the side bar and the options menu in about:addons).

Marking bug as verified fixed.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.