Repro:

Using the Cocoa version of Qt, create two different QMainWindow classes. Instantiate and show an instance of one as the application's main window, then instantiate and show an instance of the other as a child of the first (e.g., "QMainWindow* win = new ChildWindow(this)"). Now, click on the title bar of the main window. Observe that although the main window becomes active, it does not come to the front. Drag the title bar of the main window to move it, and observe that the child window also moves.

This bug does not occur in the Carbon version.

Discussion:

It looks like someone is calling -[NSWindow addChildWindow:ordered:] when the child QMainWindow is parented. From Apple's NSWindow documentation:

After the childWindow is added as a child of the window, it is maintained in relative position indicated by orderingMode for subsequent ordering operations involving either window. While this attachment is active, moving childWindow will not cause the window to move (as in sliding a drawer in or out), but moving the window will cause childWindow to move.

This matches the buggy behavior exactly. There is no good reason I can think of to call this method for anything other than a drawer window, so you can probably just remove that call and the bug will go away.