There's interaction between bridge and wireless interface if both are configured according to defaults:

• bridge with protocol-mode set to anything but none
• wireless interface set to disable-running-check=no

What happens is this: when no clients are connected to AP, the wireless interface will become inactive (bridge port shiws flag "I"). If later some client connects to this AP, wireless interface toggles to active. At this moment bridge starts to perform xSTP procedure of loop detection and duration depends on exact xSTP mode configured. During that time, bridge port is blocking traffic. It's exactly the same thing happening when ether port becomes active.
If the xSTP procedure takes longer than client is willing to wait for communication to resume, then client might just disconnect and try again. If client reconnects before bridge port becomes inactive (and after xSTP procedure completes), then client is able to resume communications and everybody is happy.

The solution: set wireless interface to disable-running-check=yes, the interface will be always running and thus never inactive as bridge port.

A separate issue is roaming aggresiveness. It's mostky up to clients to switch to another AP. You can force that to happen if you set up some access-list rules which force disconnect if client signal drops below certain threshold. But it's not trivial to find exact values so that device disconnects at the location where forced disconnect doesn't interfere with intended use.