Bugzilla

Now, due to bug 163964, the 1st URL that occurs when TB starts is ```discoverallboxes```. After that, a ```select``` for a folder (typically Inbox) occurs. Without this patch, both occur and allocate their own connection and run independently after authenticated.  
With this patch, the ```select``` URL is deferred using the existing queuing methods so that the ```discoverallboxes``` URL authenticates first and only then is the ```select``` URL pulled from queue and run in its own connection. So if there is an authentication failure on ```discoverallboxes``` it will block the ```select``` URL from attempting to login too, reducing the possibility of account lock-out as reported in comment 0.

This shouldn't slow down the access to new messages as detected by the ```select``` for users with a LOT of folders since the ```select``` is only delayed until the connection for ```discoverallboxes``` authenticates. After that, they both still run in parallel  in their own connections as was enabled in bug 163964.

Now, due to bug 163964, the 1st URL that occurs when TB starts is ```discoverallboxes```. After that, a ```select``` for a folder (typically Inbox) occurs. Without this patch, both occur and allocate their own connection, authenticate and run independently.  
With this patch, the ```select``` URL is deferred using the existing queuing methods so that the ```discoverallboxes``` URL authenticates first and only then is the ```select``` URL pulled from queue and run in its own connection. So if there is an authentication failure on ```discoverallboxes``` it will block the ```select``` URL from attempting to login too, reducing the possibility of account lock-out as reported in comment 0.

This shouldn't slow down the access to new messages as detected by the ```select``` for users with a LOT of folders since the ```select``` is only delayed until the connection for ```discoverallboxes``` authenticates. After that, they both still run in parallel  in their own connections as was enabled in bug 163964.