Those are actually two completely different phenomena.
less itself doesn't bother to check whether it's in the background (this is typical of programs that interact with terminals). The generic terminal driver in the kernel keeps track of what process¹ is in the foreground. There can only be one foreground process (more precisely one process group). The shell makes a system call (
tcsetpgrp) when the
fg builtin is used to put a process in the foreground. This system call causes the specified process to become the foreground process.
When a process tries to read from a terminal², if it is not in the foreground, the terminal driver sends the process a SIGTTIN signal. By default, this signal suspends the process (like a SIGSTOP). Similarly, a background process that tries to write to its controlling terminal receives a SIGTTOU. Most shells typically display a message like
 + suspended (tty output) less myfile when this happens.
For more information about terminals, see the description of the general terminal interface in the POSIX standard. (It's not an easy read. It's a lot more than what most users and even more programmers need to know.)
A window manager doesn't interact with terminals, so the concept of background and foreground processes in terminals doesn't apply to it. What's going on there is that the X server³ terminates when the X session terminates. The script that's calling the window manager tells what to do in the session. If you put the window manager in the background and let the session script exit without waiting for the window manager, this causes the session to end earlier than you expected.
¹ What process group, actually (e.g. a pipeline), but we don't need to get into this level of detail here.
² Only to its controlling termina in fact.
³ the back-end part of the GUI, that carries out orders to draw windows, read input and the like from applications