Mouse tracking tests

[jerch]

PR to have a solid mouse tracking test base.

The tests are a bit degraded atm to test and pass our current implementation. A new implementation should pass at least these tests to not introduce regressions. All tests have extensive comments about bugs and the desired behavior. A new implementation can work with these towards more standard conform behavior.

[jerch]

Added test stubs for modifier keys. None of these are working so all is commented out.

[textshell]

This is not actually a bit for wheel events. Xterm reports wheel events basically using the usual X11 button codes. But X11 only uses 4 buttons as wheel events and further traditional buttons use the same code space.
See https://terminalguide.netlify.com/mouse/ and the implementation for how xterm encodes the buttons.
X11 uses the buttons with the following mapping {1: left, 2: middle, 3: right, 4/5: scroll wheel, 6/7 scroll wheel left/right, 8-x: further buttons}
The xterm button encoding starts at 0, but reserves 3 as special "some button released" marker. So the buttons get shuffled to {0: left, 1: middle, 2: right, 4/5: scroll wheel, 6/7 scroll wheel left/right, 8-x: further buttons}
As the encoding of the button started with only 2 bits needed those 2 bits are used normally. The later addition of button numbers now up to 15 while the modifiers already got bits in between resulted in the bits with values 4 and 8 to be transposed up to the bits with values 64 and 128.

So while (code & 64) == 1 && (code & 128) == 0 end up encoding wheel events, (code & 64) == 1 && (code & 128) == 1 encodes button events again.

[jerch]

Oh thats kinda different from whats stated in the xterm docs itself. Seems I have to work through your links first. Also we are currently limited to 3 button mouse + wheel (cannot test higher buttons myself, not even sure if browsers agree for those on the buttons reported).

[jerch]

For my understanding - what would (code & 64) == 1 && (code & 128) == 1 encode here? Maybe I have a wrong assumption, for me doing +64 is equivalent to |64, thus the opposite &64 can test for it. Ofc this only works if the lower range does not overflow (create that bit by other means), which seems to be the case?
The example you gave just looks wrong to me as it cannot be reached by normal means. To me the 128+ rule read like the one for wheel - buttons from 8 to 11 would just be added to 128. Again I cannot test the higher buttons myself.

[jerch]

Hmm ok seems past button 11 overflow actually happens, thus my |64 == +64 does not hold here. Geez this buttonCode stuff is really awkward designed.
Edit: Yeah need to rework this and apply the "spreading bit" behavior in the test here and in the new implementation.

[jerch]

@textshell: Changed the buttonCode eval to the reverse of the xterm code. Plz have a look at it again, hope I did not miss anything.

[textshell]

I've added a few comments to the new commit. For the actually defined range your commit should work, but see my comments for ideas on simplifying it and making it a bit more meaningful with further bits set.

The encoding is a bit historical, but i don't think it could be a lot easier given the history and the strong preference for terminal sequence to use ultra compact encoding (which is still strong even today).

If you are using linux (or a linux VM) you can test with other buttons using the trick in
https://gitlab.gnome.org/GNOME/vte/issues/93#note_433817

[textshell]

The special case for code === 3 is not needed.
I think you could also use something like this:

let button = code & 3;
if (code & 128) {
    button |= 8;
}
if (code & 64) {
   button |= 4
}

This would ignore bits allocated in the future, but otherwise be very safe. But in a unit test it might be better to reject the sequence if code > 255 (like using actionS = 'invalid')

I think your code would get wrong results when confronted with code that has further bits set.

[jerch]

@textshell Yeah much cleaner.

Is there a valid way to get here code > 255? To me it seems this cannot be reached by normal "button addressing" (no +256 rule for 4th bit)? However put the code > 255 in just to be safe against malformed stuff.

[textshell]

These things are always evolving. So it's always good to think about what should happen if someone happens to allocate a new bit (which is not that hard if you have a good use case). Or in a unit test, if the code under test does something unexpected.

The button code decoding looks good now.

[jerch]

@Tyriar
Phew, MacOS tests work now. Problem was the Shift modifier, for some reason that gets not caught by the selection manager. I think we should unify the escape strategies for default actions across the platforms and maybe make it customizable so vendors can do as they wish. Already scratched that topic here #2323 (comment).

[Tyriar]

TODO: ?

[jerch]

Not sure, in the selection manager there is an explicit test against the platform. Seems it was done that way by purpose?

[Tyriar]

Hmm, what's shift meant to do? macOptionClickForcesSelection is the main mac different thing around mouse that I can think of.

[jerch]

Culprit is this code:

xterm.js/src/browser/services/SelectionService.ts

Lines 395 to 401 in 7db22c2

	public shouldForceSelection(event: MouseEvent): boolean {
	if (Browser.isMac) {
	return event.altKey && this._optionsService.options.macOptionClickForcesSelection;
	}
	return event.shiftKey;
	}

For some reason Mac is treated differently.

[Tyriar]

Oh OK, I think I used another terminal as a basis for that (user expectations for platform).

[Tyriar]

Good to merge after CI