Closed Bug 1370340 Opened 3 years ago Closed 3 years ago
Carrying class-of-service flags to redirected channels causes infinite page loading on www
On a fresh profile with today's nightly, www.walmartmoneycard.com/login doesn't load. Mozregression pointed me to bug 1356538. I just built a fresh copy of inbound with that patch reverted to test, and the page loads fine without it. (Note that I created fresh scratch profiles between tests in an attempt to rule out caching issues). My mozregression result, in case it helps: >INFO: Last good revision: 3c355512ec28828499768ed1af25e15bda3141b8 >INFO: First bad revision: b7f8c279b92268625473c916e9f34b307c924625 >INFO: Pushlog: >https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3c355512ec28828499768ed1af25e15bda3141b8&tochange=b7f8c279b92268625473c916e9f34b307c924625
Thanks for this precise report! I will look into it.
Assignee: nobody → honzab.moz
Whiteboard: [webcompat] → [webcompat][necko-active]
OK, so, bless you log analyzer! The thing here is following: - there are some transactions blocking in the window's request content (rc) - later there are also some (6+) that are not blocking, hence, are put to the queue as blocked - some of the blocking transactions are redirected - before bug 1356538 the redirected transactions didn't get the blocking flag - but now, they get it! - but, they are not given (as part of the redirect setup) the correct tab id - it's left at 0 That leads to a situation that when we try to dispatch something on a reclaimed connection, we only try five transactions for the current tab id but we never try to dispatch those with tab id = 0. This is a logical deadlock - there are blockers with tab id = 0 we never try to dispatch but there are blocked transactions for tab id = active tab we try to dispatch instead. An immediate fix is to carry the window id on redirect (no, we don't do that..), so that the blocking transactions will be found in the correct queue. The true fix (for a follow up) is to fix the background tab dispatch logic a bit so that blockers will get dispatched. Have to think more about it how.
See the previous bugzilla comment for explanation. There will be followups...
Comment on attachment 8876317 [details] [diff] [review] v1 (URGENT ONE-LINER - Carry TopLevelOuterContentWindowId to redirected HTTP channels) https://treeherder.mozilla.org/#/jobs?repo=try&revision=d9adce54fb3cae0fcdb5a941ddf4de78f02ea792
Comment on attachment 8876317 [details] [diff] [review] v1 (URGENT ONE-LINER - Carry TopLevelOuterContentWindowId to redirected HTTP channels) Dragana, if you get a chance to get to this one-liner no later than on Monday, I would greatly appreciate it. This is major issue fix. Thanks!
This one actually builds... https://treeherder.mozilla.org/#/jobs?repo=try&revision=c3d333b97ab1a92be5008ca6443f726b4452cc4d
I was just about to review it :)
Thank you both! :))
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/b9dc09ee4793 Carry TopLevelOuterContentWindowId to redirected HTTP channels. r=mcmanus
You need to log in before you can comment on or make changes to this bug.