I don't think so. This is a totally internal to the browser. For the outside word, there is no such concept as "tab", because they can be implemented in many different ways. It wasn't obvious what you are talking about, but the look at the article you referenced suggests that you are talking about using Windows Hooks for hooking up behavior of the foreign processes. But let's consider what those processes can be. Yes, if they have a main window, it will be accessible with all its top-level events, but how about the general case? Nothing can be told, really.
For example, let's consider WPF
WebBrowser control. It does not have tabs itself, so a WPF application may implement them. But WPF tabs, as all other
UIElement objects except some object exposing
Window to Windows OS, are not window objects. They work without message pumping and interact with OS only on the level of DirectX (which is closest to the hardware); and all event-based UI is connected with OS messaging system only through the top
Window object. This way, those tabs will be something totally abstracted from their role, from the OS standpoint, so there is no any predefined way to recognize them. For OS, they simply don't exist.
Now, let's imaging for a second that such tabs are implemented in the control. After all, the class
System.Windows.Controls.WebBrowser is based on
System.Windows.Interop.ActiveXHost. I don't think the tabs are part of if, but let's just imagine it. So what? Even if the control was totally based on a Windows control, the tabs can play any thinkable role, as there is not a standard telling that a browser should have tabs or some tabs should be part of a browser. Moreover, nothing (except apparent expenses) prevents anyone from implementing a browser from scratch fully based on WPF. Or on DirectX. Or something else. For Windows OS, this would be a
noumenon,
Kant's unknowable "thing-as-such" (most popular inaccurate English rendering: "thing-in-itself"). :-)
—SA
Submit an article or tip