599579 - Let context-menu module accept an optional parameter to specify which context menu is being targeted.

Status: RESOLVED DUPLICATE of bug 795522

(Add-on SDK Graveyard :: General, enhancement, P2)

Description

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100924 Firefox/4.0b7pre
Build Identifier: 

I made an addon with the SDK that targets the tabContextMenu instead of the contentAreaContextMenu.

To do this, I copied the entirety of the context-menu module into a new module, with a modified BrowserWindow function. The only thing I had to change was the following line:
let popup = this.doc.getElementById("contentAreaContextMenu");
to:
let popup = this.doc.getElementById("tabContextMenu");

It would be nice if Jetpack Core's context-menu could accept an optional value that can choose which menu is being targeted, and then override BrowserWindow automatically. (Either just the menu element's ID as a string, or something more abstract for predefined menus.)

Reproducible: Always

Comment 1

[Drew Willcoxon :adw]

Yeah, I've always thought that if people found it useful, context-menu should be broken apart into a thin high-level module that supports the content context menu and a thick low-level module that people could use to implement context-menu-related high-level modules.

But there's more to it than just the ID of the menu: different context menus have different contexts, and a low-level context-menu module would need to let different contexts be "plugged in" in addition to different IDs.  For example, the content context menu depends on the state of the page; the tab context menu depends on the state of the tab; Thunderbird's mail pane context menu depends on the mail that was context-clicked, etc.

Anyhow, the higher priority right now is making context-menu e10s-compatible.

Comment 2

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

e10s'd context-menu no longer seems to work (in the minimal way it did pre-SDK 0.9) with the modified contextmenu ID.

I'd love to work on abstracting the module a bit, if someone could point me in the right direction. (Move the low-level module into jetpack-core, leave the high-level one in addon-kit?)

Comment 3

[Myk Melez [:myk] [@mykmelez]]

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".

Comment 4

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #2)
> I'd love to work on abstracting the module a bit, if someone could point me in
> the right direction. (Move the low-level module into jetpack-core, leave the
> high-level one in addon-kit?)

Yup, that makes sense: move the low-level module into jetpack-core (now called api-utils) and leave the high-level one in addon-kit.

-> P2 Future as it isn't clear that anyone is going to have time to work on this before 1.0, although we'd certainly welcome patches to address it sooner.

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Myk, could we have a re-triage meeting planned for all of the "Future" bugs in the system? That would help get the existing bugs in Bugzilla organized better. (A bunch of the older bugs got pushed to "Future" back before 1.0 shipped, and they haven't been touched since...)

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

This'll be nice to have, but not really needed this year.

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(Pushing all open bugs to the --- milestone for the new triage system)