Bug 836066

vojtech commented:
> Right-clicking unselected grid item causes the default browser context menu to > appear.
> Right-clicking selected grid item shows the application context menu.
> I suspect this is a bug in AbstractActionTable/AbstractActionPanel right-click > handler registration.

Vojtech, I see two bugs:
1. right clicking on "empty" areas of the grid - always reproduces the issue.
2. right clicking on a 'host' quickly after selecting the hosts tab will also reproduce this issue, even though the host is selected.
(I'd attach a screenshot, but hitting print-screen causes the context menu to disapper...)

I can reproduce it in google chrome but not in Firefox.
its look like chrome bug???

I did send a patch that override the normal right click context menu.

any other ideas?

posted at: http://gerrit.ovirt.org/#/c/7716/

reproduced easily (for #1) on 3.1.0-14.el6ev with firefox 12 and IE 8

(In reply to comment #4)
> reproduced easily (for #1) on 3.1.0-14.el6ev with firefox 12 and IE 8
I didn't put it right...
It is reproducible in all browsers since its the context menu and we don't handle every widget right click context menu - my patch fix that.

the problem that I encounter (after applying my patch) in chrome is when first clicking on the main grid such as Hosts, the first click will always popup the native chrome context menu and the second is the grid widget context menu.

its look like only for the main grid (not the sub tab grids) and not for the tree so its a local bug? (and again google chrome only).

What about VNC dialog? Copying connection information is done through browser's native context menu. Additionally, we might want text copy ability on some other dialogs.

What about VNC dialog? Copying connection information is done through browser's native context menu. Additionally, we might want text copy ability on some other dialogs.

I'm able to reproduce both issues as reported by Itamar.

Issue #1 - caused by the actual table (AbstractActionTable.table field) not filling up remaining space ("empty area") vertically. This could be fixed with CSS.

Issue #2 - able to reproduce it also in Users main grid. Will investigate and compare with Shahar's patch.

Exact steps to reproduce issue #2: click outside Users tab, then click Users tab, first right-click on *each* row will produce browser-default context-menu, instead of application context-menu.

There are two methods related to table context-menu:

1. AbstractActionPanel.addContextMenuHandler() for "contextmenu" JS event, which might not be called for first right-click (not sure why)
2. AbstractActionTable.table cell preview handler (AbstractActionTable:261) that is always called, and takes care of selecting given row, for "mousedown" (right button) JS event

A quick fix would be to move logic from method 1. to method 2. for AbstractActionTable, as the second method is always called. Need to investigate why the 1st one is not called sometimes on first right-click.

Seems that before a row is selected through table selection model, it doesn't receive "contextmenu" JS events (method 1. above is not called). That's the reason why the row gets selected (method 2. above), but without application context-menu being shown (method 1. above).

IIUC this might indicate that row selection involes some additional DOM operations on the selected row. This also indicates that this issue is related to HasData widgets (e.g. CellTable within AbstractActionTable) only.

Suggested solution: use CellPreviewEvent/mousedown, in favor of ContextMenuEvent/contextmenu, for HasData widgets. If this works, I'll update the patch for review.

Issue #2 fixed, issue #1 shouldn't take too long, I'll update the patch shortly after that.

Working solution based on "contextmenu" event after all, "mousedown" is not reliable/consistent accross different browsers/platforms.

For example, FF/Win opens context menu AFTER releasing mouse button, FF/Linux opens context menu BEFORE releasing mouse button.

New patch for both issues submitted upstream: http://gerrit.ovirt.org/7820

Shahar, can you please review/verify?

(In reply to comment #14)
> New patch for both issues submitted upstream: http://gerrit.ovirt.org/7820
> 
> Shahar, can you please review/verify?
Yes its working fine,
Thanks for your help!

You are welcome, thanks for your quick response. Daniel/Shahar, can you also review the code?

(Shahar, if you agree, we could merge gerrit#7820 upstream/downstream, in favor of the original patch gerrit#7716)

(In reply to comment #16)
> You are welcome, thanks for your quick response. Daniel/Shahar, can you also
> review the code?
just +1 (forgot when I verify it...)

> 
> (Shahar, if you agree, we could merge gerrit#7820 upstream/downstream, in
> favor of the original patch gerrit#7716)
fine with me

Thank you Shahar.

Itamar/Yaniv/Einav, can you please give acks (+) if this is to be included in 3.1.0?

Patch merged upstream: http://gerrit.ovirt.org/7820

Patch submitted downstream: https://gerrit.eng.lab.tlv.redhat.com/1989

Patch merged downstream

(In reply to comment #1)
> 1. right clicking on "empty" areas of the grid - always reproduces the issue.

This one is solved.

> 2. right clicking on a 'host' quickly after selecting the hosts tab will
> also reproduce this issue, even though the host is selected.
> (I'd attach a screenshot, but hitting print-screen causes the context menu
> to disapper...)

This one is trickier and less interesting, I think. If critical, open a separate BZ (not sure will be fixed for 3.1 though).

For QA: Note that the browser's default context menu is still being opened in some scenarios (e.g. clicking in the "General" sub-tab area), which is fine since it is critical for tasks such as "copy (to clipboard)").

> 2. right clicking on a 'host' quickly after selecting the hosts tab will
> also reproduce this issue, even though the host is selected.
> (I'd attach a screenshot, but hitting print-screen causes the context menu
> to disapper...)

Did anyone try to reproduce this issue, is it still relevant? (I wasn't able to reproduce it after applying above mentioned patch.)

Created attachment 612827 [details]
right-click

Worth a thousand words - see the att. video.
I's still the same as Itamar reported. FF15, F17.

Repro:
Left click on the VM tab, then right click on VM row. Each 1st attempt shows FF menu instead RHEVM.

(In reply to comment #25)
> Created attachment 612827 [details]
> right-click
> 
> Worth a thousand words - see the att. video.
> I's still the same as Itamar reported. FF15, F17.
> 
> Repro:
> Left click on the VM tab, then right click on VM row. Each 1st attempt shows
> FF menu instead RHEVM.

Vojtech - I also managed to reproduce it (on latest downstream) - you have to left-click an item, and *really quickly* afterwards right-click it ("really quickly": like double-click, only with different mouse buttons...).
I am using FF12 on F16.

I am moving this to ON_QA, as this bug is actually solved as of si18. 
QA: Comment #22 needs to be taken into consideration when verifying - scenario 2 is not solved. Please attempt to verify only scenario 1. 
Also look in Comment #23.