A child created via fork(2) inherits a copy of its parent's signal dispositions.
That means that the child handles signals in the same way as its parents: it has the same signal handlers and the same set of ignored signals. This does not mean that sending a signal to the parent somehow also sends a signal to the child (otherwise, killing a process would also kill all of its descendants… ).
A process may be programmed with a signal handler that relays the signal to some or all of its children, but this isn't common. And it can't be done at all for signals that can't be handled such as SIGKILL and SIGSTOP. A rare case where this is done is that interactive shells propagate SIGHUP to running jobs.
In your example, with an ls process which is a child of a shell which is a child of xterm, sending a STOP signal to the xterm process only stops the xterm process. It has no impact on the shell or on ls. At some point, ls will block trying to write to the terminal, because the terminal isn't reading the data. What this means is that the write system call in the ls process will take a long time, this has nothing to do with signals.
There's a way to deliver a signal to a set of processes with parent-child relationships, but it's a decision by the caller, not by the recipient of the signal, and the set of processes has to be a process group. The purpose of process groups is to be able to send a signal to a whole shell job, even if that job consists of multiple processes (e.g. a pipeline).
