#21886: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on ESR52 with e10s off -------------------------------------------------+------------------------- Reporter: gk | Owner: gk Type: defect | Status: | needs_review Priority: High | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: Keywords: tbb-usability, tbb-7.0-must-alpha, | Actual Points: ff52-esr, TorBrowserTeam201705R, | GeorgKoppen201705 | Parent ID: | Points: Reviewer: | Sponsor: | Sponsor4 -------------------------------------------------+------------------------- Changes (by gk):
* cc: arthuredelstein (added) * keywords: tbb-usability, tbb-7.0-must-alpha, ff52-esr, TorBrowserTeam201705, GeorgKoppen201705 => tbb-usability, tbb-7.0-must-alpha, ff52-esr, TorBrowserTeam201705R, GeorgKoppen201705 * status: needs_information => needs_review Comment: Okay, I am not fully done here as I seem to still have some details missing (I need more detailed logs at that point) but so far the patch in the attachment fixes things for me and looks good according to my logs I took for the debugging purposes. I have a branch `bug_21886_v3` (https://gitweb.torproject.org/user/gk/tor- browser.git/commit/?h=bug_21886_v3&id=96a9fe10689345b0410b6ee25134de4e27c7c883) for review. The problematic NoScript part is: {{{ if (IOUtil.isMediaDocOrFrame(req, contentType)) { IOUtil.suspendChannel(req); Thread.delay(() => IOUtil.resumeParentChannel(req), 100); } isMediaDocOrFrame(channel, contentType) { try { let cpType = channel.loadInfo.externalContentPolicyType; if (cpType === 7 || (cpType === 6 && /^(?:video|audio|application)\//i.test(contentType === undefined ? channel.contentType : contentType))) { try { return !/^attachment\b/i.test(req.getResponseHeader("Content- disposition")); } catch(e) { } return true; } } catch (e) { } return false; }, }}} I don't really understand what `hread.delay(() => IOUtil.resumeParentChannel(req), 100);` but I suspect that the problems we are seeing are caused by it. What happens deeper down in the stack is the request being closed after about 32768 bytes are handled because calling `onDataAvailable` is resulting in an error that gets back to `OnStateStop` (`NS_ERROR_UNEXPECTED`): {{{ [Main Thread]: D/nsStreamPump nsInputStreamPump::OnInputStreamReady [this=7f4591466180] [Main Thread]: D/nsStreamPump OnStateTransfer [this=7f4591466180] [Main Thread]: D/nsStreamPump Available returned [stream=89904d00 rv=0 avail=32768] [Main Thread]: D/nsStreamPump calling OnDataAvailable [offset=0 count=32768(32768)] [Main Thread]: D/nsHttp nsHttpChannel::OnDataAvailable [this=7f459a4da000 request=7f4591466180 offset=0 count=32768] [Main Thread]: D/nsHttp sending progress and status notification [this=7f459a4da000 status=804b0006 progress=32768/60562619] [Main Thread]: D/nsStreamPump OnStateStop [this=7f4591466180 status=8000ffff] [Main Thread]: D/nsHttp nsHttpChannel::OnStopRequest [this=7f459a4da000 request=7f4591466180 status=8000ffff] }}} I'd like to keep this ticket open until we understand in detail what is going wrong but I think having the patch in the alpha can't hurt. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21886#comment:25> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs