Network (UNC) Tabs and user authentication

[Dark-Star]

Hi,

I just noticed a small (but annoying) bug.

Suppose you have 3 tabs oben, Tab A, Tab B and Tab C (in that order).
Let's say Tab A and Tab C show some path on your local disk, and Tab B is connected to an UNC path to some device on your network.

Now let's also say that the network device requires a username and password on the first connection.

If you are now on Tab A, and press Ctrl-Tab to switch to tab B, then there will be a slight delay and then Windows pops up the "please enter your user name and password" dialog box. Now comes the buggy part: if you decide you want to tab through to the next tab, tab C, before the Windows dialog box pops up, then after entering your username/password, TC will change Tab C to the network path instead of (re-)connecting Tab B. So you now have both tabs B and C showing the network path.

-Darkstar

[ghisler(Author)]

Sorry, I don't think that I can prevent that - the dialog comes from Windows, not TC itself. TC cannot know for which part this dialog is shown (TC only 'sees' that the focus is taken away).

[Dark-Star]

But it is different for example from waiting for a very slow drive to respond (in that case TC blocks completely).
So the waiting must happen somewhere in the background for net connections. And if it's waiting in the background, it should be possible to give this waiting thread some info on which tab it is working.

Or, as different solution, instead of changing the current tab unconditionally, simply check all other tabs to see if one of these matches the new UNC path exactly, and if so, update that one instead of the current tab...

-Darkstar

[Hacker]

I can confirm that similar things happened to me, though I have never tried to reproduce it. Basically, if you are switching tabs and one of them points to a dir that is slow to read (many many files, external drive in standby mode, etc.) and you keep trying to switch tabs (before the "Connect" dialog appears), sometimes TC changes the path of the newly switched-to tab to the path of the slow to read tab.
I assume this is not easy to troubleshoot, I just want to confirm that such a condition exists.

Roman

[umbra]

Issues, when content of one tab affects path in other tabs, are not rare at all (example1, example2). Some of them got fixed, others not. Maybe it's time to consider separating tabs with their respective panels to completely independent objects in their own threads to fix this kind of bugs, to prevent constant freezes caused by slow drives or wdx plugins and to enable features like tab-specific filters.

[ghisler(Author)]

2umbra
This does not help because Windows just displays the dialog by itself - it doesn't tell TC where it came from.

[MarcinW]

If Total commander used separate thread for each tab, there could be a possibility of detecting such an unexpectedly displayed "enter password" system dialog box (but only if operating system displays this dialog box in the context of the thread that tries to connect to the network). We could use EnumThreadWindows API call, and check for windows with "#32770" class name (this is a class name for all dialog boxes). There is also an useful GetWindowThreadProcessId API function.

However, as far as I can see using a debugger, all tabs use same thread.

[ghisler(Author)]

Are you sure that the dialog is shown in the context of the calling thread, and not the main UI thread?

[MarcinW]

I wasn't able to reproduce this system dialog box, which asks for user name and password. I don't have any network device that requires such an authorization, or I don't know how to enable it, maybe someone could give me detailed instructions how to achieve this dialog box.

But let's make for the moment the following assumptions:
- TC creates separate thread for each tab (which is currently not true)
and
- one of the tabs causes Windows to display dialog box
and
- this dialog box is in the came thread that the tab (tab thread calls some network API function and this function simply displays dialog box before connecting).

Only for these 3 assumptions it could be possible to detect potential dialog box - by using EnumThreadWindows API, GetWindowThreadProcessId API or by hooking message queue of the thread and detecting WM_INITDIALOG message (hooking would be required, because modal dialogs have their own, internal message loop, which we can't control directly). Currently all tabs use the same thread, so it's impossible to distinguish them.