Bugzilla

Good question, it's complicated and I wanted you to spare the details. Happy to explain.

The 115 problem was a race condition which has always been present, but was made very apparent and common only last year, when Office365 disabled Basic auth, which made certain HTTP calls always fail with a 401 (and apparently fail very fast, faster than the ISPDB responds) and triggered this case far more often.

In TB 128, that race does not actually happen, by coincidence, because the new OAuth2 prompt during AutoDiscover blocked the racing function. Nonetheless, we submit the code change for trunk as well, because a) the fix makes the code both more reliable and more readable, and b) to allow easier testing on trunk.

In TB 128, there is another regression caused by bug 1397646, which made it so that XMLHttpRequest.statusText returns nothing, and which caused our code to fail. This problem is fixed only in the TB 128 patch and does not apply to TB 115, so we left that part out of the TB 115 patch.

Good question, it's complicated and I wanted you to spare the details. Happy to explain.

The 115 problem was a race condition which has always been present, but was made very apparent and common only last year, when Office365 disabled Basic auth, which made certain HTTP calls always fail with a 401 (and apparently fail very fast, faster than the ISPDB responds) and triggered this case far more often.

In TB 128, that race does not actually happen, by coincidence, because the new OAuth2 prompt during AutoDiscover blocked the racing function. Nonetheless, we submit the code change for trunk as well, because a) the fix makes the code both more reliable and b) more readable, and x) to allow easier testing on trunk.

In TB 128, there is another regression caused by bug 1397646, which made it so that XMLHttpRequest.statusText returns nothing, and which caused our code to fail. This problem is fixed only in the TB 128 patch and does not apply to TB 115, so we left that part out of the TB 115 patch.

Good question, it's complicated and I wanted you to spare the details. Happy to explain.

The 115 problem was a race condition which has always been present, but was made very apparent and common only last year, when Office365 disabled Basic auth, which made certain HTTP calls always fail with a 401 (and apparently fail very fast, faster than the ISPDB responds) and triggered this case far more often.

In TB 128, that race does not actually happen, by coincidence, because the new OAuth2 prompt during AutoDiscover blocked the racing function. Nonetheless, we submit the code change for trunk as well, because a) the fix makes the code both more reliable and b) more readable, and c) to allow easier testing of the change on trunk.

In TB 128, there is another regression caused by bug 1397646, which made it so that XMLHttpRequest.statusText returns nothing, and which caused our code to fail. This problem is fixed only in the TB 128 patch and does not apply to TB 115, so we left that part out of the TB 115 patch.

Good question, it's complicated and I wanted you to spare the details. Happy to explain.

The 115 problem was a race condition which has always been present, but was made very apparent and common only last year, when Office365 disabled Basic auth, which made certain HTTP calls always fail with a 401 (and apparently fail very fast, faster than the ISPDB responds) and triggered this case far more often.

In TB 128, that race does not actually happen, by coincidence, because the new OAuth2 prompt during AutoDiscover blocked the racing function. Nonetheless, we submit the code change for trunk as well, because a) the fix makes the code both more reliable and b) more readable, and c) to allow easier testing of the change on trunk.

In TB 128, there is another regression caused by bug 1397646, which changed the implementation so that `XMLHttpRequest.statusText` now returns nothing for HTTP2 calls, and this change caused our code to fail. This problem is fixed only in the TB 128 patch and does not apply to TB 115, so we left that part out of the TB 115 patch.

Good question. It's complicated. Happy to explain.

The 115 problem was a race condition which has always been present, but was made very apparent and common only last year, when Office365 disabled Basic auth, which made certain HTTP calls always fail with a 401 (and apparently fail very fast, faster than the ISPDB responds) and triggered this case far more often.

In TB 128, that race does not actually happen, by coincidence, because the new OAuth2 prompt during AutoDiscover blocked the racing function. Nonetheless, we submit the code change for trunk as well, because a) the fix makes the code both more reliable and b) more readable, and c) to allow easier testing of the change on trunk.

In TB 128, there is another regression caused by bug 1397646, which changed the implementation so that `XMLHttpRequest.statusText` now returns nothing for HTTP2 calls, and this change caused our code to fail. This problem is fixed only in the TB 128 patch and does not apply to TB 115, so we left that part out of the TB 115 patch.

Good question. It's complicated, so I wanted to spare you the details. Happy to explain.

The 115 problem was a race condition which has always been present, but was made very apparent and common only last year, when Office365 disabled Basic auth, which made certain HTTP calls always fail with a 401 (and apparently fail very fast, faster than the ISPDB responds) and triggered this case far more often.

In TB 128, that race does not actually happen, by coincidence, because the new OAuth2 prompt during AutoDiscover blocked the racing function. Nonetheless, we submit the code change for trunk as well, because a) the fix makes the code both more reliable and b) more readable, and c) to allow easier testing of the change on trunk.

In TB 128, there is another regression caused by bug 1397646, which changed the implementation so that `XMLHttpRequest.statusText` now returns nothing for HTTP2 calls, and this change caused our code to fail. This problem is fixed only in the TB 128 patch and does not apply to TB 115, so we left that part out of the TB 115 patch.

Good question. It's complicated, so I wanted to spare you the details. Happy to explain.

The 115 problem was a race condition which has always been present, but was made very apparent and common only last year, when Office365 disabled Basic auth, which made certain HTTP calls always fail with a 401 (and apparently fail very fast, faster than the ISPDB responds) and triggered this case far more often.

In TB 128, that race does not actually happen, by coincidence, because the new OAuth2 prompt during AutoDiscover waits for user input and blocked the racing function. Nonetheless, we submit the code change for trunk as well, because a) the fix makes the code both more reliable and b) more readable, and c) to allow easier testing of the change on trunk.

In TB 128, there is another regression caused by bug 1397646, which changed the implementation so that `XMLHttpRequest.statusText` now returns nothing for HTTP2 calls, and this change caused our code to fail. This problem is fixed only in the TB 128 patch and does not apply to TB 115, so we left that part out of the TB 115 patch.