1096530 - Necko doesn't always notify listeners when a cached and suspended redirect is canceled

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Blake Kaplan (:mrbkap) (inactive)]

I found this testing the patch for bug 1088457.

STR:
0. Enable tracking protection
1. Go to <http://people.mozilla.org/~mchew/test_tp.html>
2. Disable tracking protection for the site via the favicon/Larry icon.
3. After the site refreshes, re-enable tracking protection

Expected results:
The page completes loading and the throbber stops spinning.

Actual Results:
The page appears to be loaded, but the throbber continues forever.

The problem is that the first successful load of one of the resources on the page (doubleclick.net in this case) caches that it is a redirect. Then, when we load the page with tracking protection enabled, we do the following:

1. Detect the cached redirect
2. Suspend the channel
3. Try to continue the redirect (via nsHttpChannel::HandleAsyncRedirect)
   -> This bails early and waits for the call to Resume()
4. Cancel the channel due to tracking protection
5. Resume

However, there's a small bug in HandleAsyncRedirect, where if we canceled the channel in the meantime, we don't ever create the redirect channel *or* notify our listener of the error.

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: patch v1

This ensures that we notify our listener.

Comment 2

[Patrick McManus [:mcmanus]]

thanks blake!

Comment 3

[Patrick McManus [:mcmanus]]

Comment on attachment 8520123 [details] [diff] [review]
patch v1

Review of attachment 8520123 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm - the lack of donotifylistener before this patch would definitely hang the channel

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e8597e1b2f15

Thanks for the review!

Comment 5

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e8597e1b2f15