Has this been fixed in a later release?

Mass-closing what appear to be old bugs.  If this is still a bug for you, feel
free to open it again.  Filter on the phrase "Ross is breaking things again" if
you get lots of these messages.

Stanislav Brabec <utx@penguin.cz> mailed me with the following
information:

In Gnome 1.4 the problem is still present.
Simple test is mc. Run mc, press Shift and Right Button. You should
see gnome-terminal menu, but you don't.

Confirmed on 1.4.0.6

Not sure this is a bug. We want to let some console apps get the mouse
events and it's hard to decide when that is not the case.

There is following mouse click convention, introduced by xterm:
- If application requests mouse click watching, simple mouse clicks
are delivered to application.
- Shift-mouse clicks are never delivered to application and are used
for purposes of terminal.

This behavior is not present nor in Gnome1's gnome-terminal
(Shift-clicks are not delivered to gnome-terminal) nor Gnome2's
gnome-terminal (aka profterm) (simple right click should be delivered
to application, if requested, in such case menu should be accessible
only via Shift-right click).

Havoc, care to comment on this?

Should be moved to vte or libzvt as appropriate.
I guess it's fine to do, as long as Shift is down.

Moving to libzvt.

Moving to vte. It seems that this doesn't work in xterm either though...

Works for me in xterm (xorg-6.8.1, SuSE Linux 9.2), as described above. Does not
work in gnome-terminal.

xterm

right click - block marking (function of xterm)

mc
right click - select/deselect (function of mc)
Shift + right click - block marking (function of xterm)

I see the following:

- left click on mc menus works in both g-t and xterm
- shift right click to do block marking (while runnning mc) only works under xterm
- shift right click seems to work when not running an application in g-t

Does this sum up this bug? And do you see the same behaviour on SuSE?

No. Block marking is a default function of xterm for right click. Default
fonction for gnome-terminal is menu pop-up and it's OK.

At least in SuSE 9.2 I see following: If mc catches right click, it does
toggle-selection. In xterm, it is possible by simple right click. Shift right
click is passed directly to xterm and does block marking. In gnome-terminal,
using toggle selection is not possible, because click is never delivered to mc.

There is a sum of expected behavior:

Simple right click should be delivered to terminal application, if terminal
application can handle it. If it does not, it should be passed to terminal emulator.

Shift right click should passed directly to terminal emulator and do the same as
simple right click does for terminal applications not handling it.

mc = terminal application
gnome-terminal = terminal emulator

Exactly the same already works for left and middle clicks (and even for scroll
wheel).

Yeah, I see this as well. Need to compare what xterm does and what vte does
codewise I guess.

I almost tracked this down.  Currently vte simply ignores right-click and passes it on to the application.  gnome-terminal on the other hand, reacts on right-clicks that happen without any modifiers, and pops up the context menu.

We should change these to:

  * gnome-terminal should also popup if shift is pressed with right click. (it's all in terminal_screen_button_press_event)

  * when shift is not pressed, gnome-terminal should first emit the right click signal to the vte terminal, and popup a menu only if the signal was not handled by vte.

  * vte should be changed to return FALSE on mouse events when it didn't handle them and the client had not requested to be notified of those kind of mouse events.

I don't quite know how to do the second step, although I'm sure it's quite possible and easy.

Implemented this.  Patches for vte and gnome-terminal follow.  Please review.

What is the difference of your implementation of right click handling and left and middle click handling?

Please note, that I have just filled new bug, which describes the same problem with mouse wheel events: bug 338194

The difference is that right-click is handled by gnome-terminal, while others are handled by vte.  I'll look into bug 338194 later.  Doesn't look hard to do.

Ah, attached to the wrong bug :(.  Here they are:

vte patch: attachment 63289 [details] [review].
g-t patch: attachment 63290 [details] [review].

I've been using g-t with these patches since, and unfortunately it doesn't look good.  Seems to me like ncurses does request to be notified of the mouse events no matter whether the application uses them or not.  So in vim and pine I keep wondering why right-click on URLs doesn't work anymore, to remember that I have to press shift too...   Not sure if this can be solved at all.

You can use the behavior of xterm as a reference. g-t should pass mouse clicks/rolls in exactly the same way. I don't see a problem there - Shift+Right Button should work in any case.

And what is the xterm behavior?  My xterm doesn't have a context menu enabled by right-click, so I don't see how we can use the behavior of xterm as a reference.

xterm behavior:
without Shift (or other modifier key) - if application requests clicks, pass clicks to application, otherwise handle click by terminal
with Shift (or other modifier key) - do not pass click to application, handle click by terminal

The meaning of click for terminal can differ, but meaning for application should be the same.

Right click in xterm does additive selection, i g-t context menu.

*** Bug 108230 has been marked as a duplicate of this bug. ***

*** Bug 86943 has been marked as a duplicate of this bug. ***

*** Bug 610629 has been marked as a duplicate of this bug. ***

(In reply to comment #23)
> xterm behavior:
> without Shift (or other modifier key) - if application requests clicks, pass
> clicks to application, otherwise handle click by terminal
> with Shift (or other modifier key) - do not pass click to application, handle
> click by terminal

That's exactly what g-t does also.  Did you read my previous comments as well as comment #20?

>> without Shift (or other modifier key) - if application requests clicks, pass
>> clicks to application, otherwise handle click by terminal
>That's exactly what g-t does also.

Not for me in gnome-terminal-2.28.2. Expecting selection with right click in mc, I get g-t context menu.

> Did you read my previous comments as well
> as comment #20?

Yes, I read.

I can imagine solution that can satisfy everybody: Make it configurable:

Simple way:
Pass clicks to application
Left click: With Shift/Without Shift/Always/Never
Right click: With Shift/Without Shift/Always/Never
Middle click: With Shift/Without Shift/Always/Never
Scroll wheel: With Shift/Without Shift/Always/Never

Advanced way:
Pass clicks to application
Left click: With modifier/Without modifier/Always/Never  Modifier: Shift/...
Right click: With modifier/Without modifier/Always/Never  Modifier: Shift/...
Middle click: With modifier/Without modifier/Always/Never  Modifier: Shift/...
Scroll wheel: With modifier/Without modifier/Always/Never  Modifier: Shift/...

The current behavior in xterm:
Left: Without Shift, Right: Without Shift, Middle: Without Shift, Scroll wheel: Without Shift

The current behavior in g-t:
Left: Without Shift, Right: Never, Middle: Without Shift, Scroll wheel: Without Shift

Both xterm and g-t have special behavior for Scroll wheel: If application requests scroll wheel, it is passed only wihout Shift. With Shift, nothing happens: Event is not sent to the application nor the terminal.

(In reply to comment #28)
> >> without Shift (or other modifier key) - if application requests clicks, pass
> >> clicks to application, otherwise handle click by terminal
> >That's exactly what g-t does also.
> 
> Not for me in gnome-terminal-2.28.2. Expecting selection with right click in
> mc, I get g-t context menu.

Sorry, my bad.  If we made it behave like xterm, there will be the issue in comment 20.

I'm leaning toward going ahead and committing that patch though.  Right now right-click is never sent...

ChPe, what do you think?

>I'm leaning toward going ahead and committing that patch though.  Right now
>right-click is never sent...

Hi,

I'm new to the conversation, but hopefully I can bring a newbies perspective :)

I believe right-click should go to the application, and shift-right-click should go to the terminal.

All the apps, that support it, say right-click in their man pages. The terminal should honor that!

That's my thought. YeeHaaw! Patch it up!!!

Thank you!

still valid for gnome-terminal-2.30.1. Xfce terminal which also use vte behaves correctly.

A 13 year old bug, still not resolved :(

Behdad, your comment 20 seems to be incorrect or outdated to me. First, neither vim nor pine (alpine, actually) use ncurses (checked on Ubuntu Saucy). Second, apps using ncurses (e.g. mutt) that don't use mouse don't initialize it either (the mouse cursor stays a vertical bar, and left mouse button highlights without shift needed).

I think the desired behavior is clear. Right click should go to the application if it's interested in mouse events. Popup is fine for Shift+rightclick, or when the application doesn't care about mouse.

Created attachment 257470 [details] [review]
vte patch, updated to 0.34.9

Created attachment 257471 [details] [review]
g-t patch, updated to 3.10.1

Egmont, if you are comfortable with git please push out a git tree so I can at least easily cherry-pick.  Unfortunately I have very little time for vte these days.  You really should be pushing out patches yourself, but if you don't like to do that, having a git tree is a more comfortable middle ground.  Thanks!

I've created https://github.com/egmontkob/vte-0-36-egmont with my all proposed vte patches.

Committed to vte-0-36 and g-t master.

Moving to vte to keep open for vte-next work.