[MC-108553] click events on signs with relative commands are inconsistent

Click events on signs are sometimes processed as the clicking player and sometimes as the sign itself.

To reproduce, put down a sign and put a command block on top of it with the respective command:

/blockdata ~ ~-1 ~ {Text2:"{\"text\":\"\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"[enter Command here, see below]\"}}"}

/blockdata ~ ~-1 ~ {Text2:"{\"text\":\"\",\"clickEvent\":{\"action\":\"run_command\",\"value\":\"[enter Command here, see below]\"}}"}

Activate the command block, right-click the sign.

Test-cases:

Command:
```
/say @p
```
```
/say @p
```
This outputs "[name] name" of the clicking player, even if another player is closer to the sign.
Command:
```
/say @a[c=1]
```
```
/say @a[c=1]
```
Same as @p.
Command
```
/say @a[c=2]
```
```
/say @a[c=2]
```
Outputs the name of right-clicking player in square brackets but states the two closest players to the sign, in order of distance.
Command
```
/say @e[c=1]
```
```
/say @e[c=1]
```
Same as @p.
Command
```
/say @e[c=2]
```
```
/say @e[c=2]
```
Outputs the name of the clicking player in square brackets but states the two closest entities to the sign, in order of distance.

Command

/setblock ~ ~2 ~ gold_block

/setblock ~ ~2 ~ gold_block

Sets a gold block 2 blocks above the sign.

Command
```
/teleport @p ~ ~2 ~
```
```
/teleport @p ~ ~2 ~
```
Teleports the player that clicked the sign 2 blocks above the sign.

These test-cases show an inconsistency in the processing of the commands on signs.

Comments 1

Skylinerw 2016-10-10T20:23:47Z

To clear up what's going on, which is consistent across all commands:

There is a single object containing all information about what is executing the command (I'll refer to it as the "executor"), which is used no matter what the context is for command execution (player-executed, command-block-executed, sign-executed, /execute-executed). Included in that set of data is a "sender", an "origin", a "permission level", a "CommandStats target", and a "display name" (among other things).

The sender will be set to that of the clicking player. Sender bias always targets the sender if, after a selector is processed, the sender is still in the list of possible targets and c is set to 1 (or the selector can only obtain 1 target by default), which is the case for @p and @a[c=1]. It does not take into consideration if the origin doesn't match up (MC-80893).
The origin will be set to that of the sign that was clicked, which is why /setblock and /teleport behave in that manner (see MC-62255). Anything that deals with XYZ origins will be dealing with the sign's origin. This allows modifying the clicked sign without knowing where the sign is, and /execute can otherwise be used to change the origin to that of the clicker (by using sender bias described above). Selectors use that origin, which is why the @a[c=2] and @e[c=2] selectors obtain targets starting at the sign (and technically @a[c=1] does too, but see MC-78006 as to why the sender isn't targeted for the other selectors).
The permission level is set to same value as command blocks, which is why a player clicking does not require OP status to execute the command.
The receiver of CommandStats data is set to the sign. This is necessary in order for signs to make use of its CommandStats. The clicking player will not have their CommandStats triggered, so /execute is necessary to do so (which makes use of sender bias to always target the clicking player).
The display name is set to that of the clicking player, which is where /say gets the display name from.

There are no exceptions for a command being run. The interaction with the executor does not explicitly change if it's a sign versus a command block, player, etc. All that changes is what the data is stored in the "executor" object.