>>Thing is, tabbing out and perhaps answering later works so well that the case of "new" is surprizing. It is not a big deal, but IMO it points to OOP/containment to be grouped at a wrong level - if encountering such things myself I'd probably put it on a low to middle priority level to fix if general refactoring is in order.
>
>You totally lost me here. What I am saying is that this is an entire application, not like a Web page. So, a lot of invisible processes work in the background and the full interface has to be loaded and used as is in order for things to work. Sometimes, a user would right click a message from a message map to open in a new window. In such circumstances, we cannot garantee its support as the user decided to move it out of the container. It's like I want the car to continue to work even if I remove the wheels.

For me the goal is to build the entire application out of building blocks which are self-continained and thereby easier to use. I am guessing that the "new" in its own, uncontained tab is missing a property and/or function to check/fire when the forum cbo changes. Trying to build my own car example: In older cars the doors, as long they had manual window cranks, you could replace the whole door and everything would work and you could crank the window up and down even before exchanging to test - all components are inside the building block. Will follow up in post in observations in mobile, makes more sense over there...