Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] Reporter
	Description • 11 years ago

The menu should contain the following generic entries:
- Copy
- Paste
- Select All

Tools also need to be able to add their own entries.

	Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] Reporter
	Comment 1 • 11 years ago

This patch is very basic and doesn't really need to be used.

The main issue is that the tools are all either XUL or XHTML. The first job would be to convert all of our tools to HTML5.

Paul had a clear plan here so I guess we can leave it to him.

Because we plan on converting to HTML iframes as opposed to XUL iframes I suspect that it makes sense to do this at the same time.

	Luke
	Comment 2 • 11 years ago

Interesting. Sorry if this is off-topic, but what are the benefits of HTML5 over XUL? As an addon developer I always thought XUL was easier to use, and better for extensibility and UI. Will we still be able to use overlays to extend the devtools when they are HTML5?

	Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] Reporter
	Comment 3 • 11 years ago

Neil: This half finished patch is not so important but lets you see where at least one of our menus need to be.

This is the kind of hack that we are having to use in order to add context menus to the DevTools toolbox as it is not in tabbrowser so contextmenu attributes just plain ol' don't work:

this.element.addEventListener("mousedown", event => {
  let win = this.doc.defaultView;
  win.focus();

  win.setTimeout(() => {
    this.ruleView._contextmenu.openPopup(
      event.target.ownerDocument.documentElement,
      "overlap", event.clientX, event.clientY, true, false, null);
  }, 0);
}, false);

I am not sure why we need the setTimeout here but the context menu does not appear without it.

Anyhow, we would like to switch to using HTML5 context menus instead but, obviously, we simply don't have the magic beans that power them. You happen to live in the land of magic beans so you seem like the right person to ask.

Is there anything that can be done here?

(In reply to Luke from comment #2)
> Interesting. Sorry if this is off-topic, but what are the benefits of HTML5
> over XUL? As an addon developer I always thought XUL was easier to use, and
> better for extensibility and UI. Will we still be able to use overlays to
> extend the devtools when they are HTML5?

HTML5 context menus just work better for our tools mostly because our tools are HTML documents. Of course, we will be providing an API to make it easy for extension developers to use.

	Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] Reporter
	Comment 4 • 11 years ago

Jan: It seems like you implemented the HTML5 context menu so you must be the best person to ask.

Ignore this patch, it's only purpose was to show where we want to add the menu.

In our web developer toolbox we want to use HTML5 context menus but adding the contextmenu attribute etc. does nothing. We suspect that this is because our toolbox lives outside of tabbrowser.

Do you have any insights or know of any workaround for this situation?

	Jan Varga [:janv]
	Comment 5 • 11 years ago

I think the original HTML5 context menu implementation is flexible in this regard, so you should be able to use it quite easily.

Take a look at nsContextMenu.js, especially initMenu(). It calls PageMenu.maybeBuildAndAttachMenu(htmlNode, xulMenu).

See also, browser.xul:
<menupopup id="contentAreaContextMenu" pagemenu="start"

the "pagemenu" attribute is used to find an insertion point for generated xul menu items (from HTML5 menu items)

	Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe] Reporter
	Comment 6 • 11 years ago

This is a large change with little that will be visible to the user. I have logged bug 917863 to quickly add a XUL context menu in the meantime.