Comment 1 Rüdiger Herrmann 2009-04-22 13:57:13 EDT

This should be solved in qooxdoo. Filed this bug at:
  2286: Use 'native' context menu for TextField if none was attached explicitly
  http://bugzilla.qooxdoo.org/show_bug.cgi?id=2286

Comment 2 Rüdiger Herrmann 2009-04-27 05:41:47 EDT

Apparently, the qooxdoo guys aren't willing to fix this. 
However a workaround is proposed:
1. Enable the native context menu globally
2. Attach a context menu event listener to the application root. This listener checks whether the event target is an input element. If the target isn't an input element it calls e.preventDefault(). This blocks all context menus except the ones on input fields
3. If you attach a local event listener on a textfield make sure to call e.preventDefault() in the handler.

Comment 3 Markus Wolf 2009-05-19 06:00:43 EDT

Here is another possible patch for the problem:

qx.Mixin.define("de.nmmn.ContextMenuPatch", {
  construct : function(child) {
    if (this._tree) {
      this._tree.addEventListener("contextmenu",
        this._onContextMenuPatch, this);
    }
  },
  "members" : {
    _onContextMenuPatch : function(event) {
      var menu = this.getContextMenu();
      if (menu != null) {
        event.preventDefault();
      }
    }
  }
});
qx.Class.include(org.eclipse.swt.widgets.Tree, 
  de.nmmn.ContextMenuPatch);

This mixin is currently only aware of the tree implementation but should be easy to extend to other widgets. It disables the native contextmenu if there is a custom one for the tree widget.

Comment 4 Asen Draganov 2009-06-11 08:18:27 EDT

Created attachment 138921 [details]
Proposed patch with side effects

The workaround from comment #2 has been applied. Generally it did the job.
However there are also two unwanted side effects:

1. The browser context menu appears on all disabled widgets, because no events
are propagated in a disabled state.
2. If there is an explicitly set context menu on a parent of the input element,
the 'native' browser menu doesn't appear on it as well.

The corresponding qooxdoo bug has been reopened for this reason.

Comment 5 Tim Buschtoens 2009-09-14 12:01:02 EDT

Created attachment 147115 [details]
Another solution

This patch works by intervening where the context menu is actually surpressed (EventHandler.js) and calling a funtion in the rwt.Menu-class to see if the Widget ins question allows native context menus. However, this also means that the Qooxdoo-framework itself is altered and qx.js has to be build again.

Comment 6 Ivan Furnadjiev 2009-09-14 12:25:04 EDT

What I don't like in the last patch is mixing qx framework with rwt classes. Maybe we can use a "mixin" to achieve the same task without putting the call to RWT classes inside the qx framework.

Comment 7 Tim Buschtoens 2009-09-15 12:47:10 EDT

Created attachment 147226 [details]
Same solution using callback-function

This uses a callback-function to prevent any qx->org.eclipse dependency.

I think the same effect could also be achieved patching MouseEvent with a Mixin. (It might depend on how mixin-constructors are called). That would remove the necessity to change the Qxoodoo-framework, but it would also mean another mixin-file.

Comment 8 Tim Buschtoens 2009-09-17 11:27:19 EDT

Created attachment 147447 [details]
Third solution using mixin

This patch uses a mixin to patch MouseEvent on runtime and does not change the Qooxdoo-Framework directly. It now also respects the border and padding of input-elements by checking not only the target-widget of the event, but also the target-node.

Comment 9 Tim Buschtoens 2009-09-21 09:07:08 EDT

Created attachment 147689 [details]
4th path

Using the mixin-solution does not work with disabled widgets, so this goes back to the callback-solution.

Comment 10 Tim Buschtoens 2009-09-21 09:19:25 EDT

Created attachment 147690 [details]
4th patch

(Previously commited wrong file.)

Comment 11 Tim Buschtoens 2009-09-21 10:43:41 EDT

qx.js/qx-debug.js have to be rebuild for this to work.

Comment 12 Rüdiger Herrmann 2009-09-21 11:47:00 EDT

Applied patch #4 to CVS HEAD