So right now, rapid network changes will trigger a false dead signal and seemingly remain that way. However, it is not actually dead or disabled in any way, just idle. It will still become active, and after it returns to an idle state, it displays the correct icon.
This happens in a no-internet environment and when behind a captive portal. (Which, given that I am frequently behind captive portals, this likely happens more than with most users).
Proposed initial fixes:
A) set background to re-initialize flashproxy.js at regular intervals, if the status is something other than active.
B) force dead-status flash proxies to retry connection every 10 minutes.
Future upstream fixes:
Change dead to waiting, since it seems to be waiting for a real connection
Ensure that flash proxies with dead/waiting status occasionally re-check connection
After more testing, this seems to be an upstream quirk. It's idle but declaring its status as dead for some reason. Still working on an upstream fix (B) but setting an interim patch to keep users from mistakenly thinking that their network settings are broken.
So right now, rapid network changes will trigger a false
deadsignal and seemingly remain that way. However, it is not actually dead or disabled in any way, just idle. It will still become active, and after it returns to an idle state, it displays the correct icon.This happens in a no-internet environment and when behind a captive portal. (Which, given that I am frequently behind captive portals, this likely happens more than with most users).
Proposed initial fixes:
flashproxy.jsat regular intervals, if the status is something other thanactive.dead-status flash proxies to retry connection every 10 minutes.Future upstream fixes:
deadtowaiting, since it seems to be waiting for a real connectionEdit: this is also Tor issue #11400.
The text was updated successfully, but these errors were encountered: