420720 - download manager "hung" scanning download for a while

Status: UNCONFIRMED

(Toolkit :: Downloads API, defect)

Description

[timeless]

Attachment: windbg notes

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022806 Minefield/3.0b4pre

https://bugzilla.mozilla.org/attachment.cgi?id=306828

I was trying to view this link (it's a .gz). Minefield me what I wanted to do, i said open with winzip. it did, i viewed the contents.

Then I checked download manager and noticed it said it was scanning the file (it was <1/3 done). Which is odd. Minefield shouldn't really be opening files that aren't scanned ....

FWIW, I have IMEs configured/available for Chinese, Korean, Japanese, and Vietnamese. I believe the stuck UI thread is basically waiting for the scanner. I really don't like the fact that my UI is losing to the scanner. The loader lock is fairly global (I have no idea why the IME would have decided to do work when it did, especially not a load, but clearly it did. I'd expect the scanner to do loads for scanning, and again would request that we reconsider in process scanning in favor of proxying to another process).

As for time. I probably had a minute to read the attachment before I noticed it wasn't done scanning. And then it took a while before it actually got around to being done. Of course, the debugger was attached to the process the whole time, which may influence timings (but it should not influence the sequence of events!).

Comment 1

[Shawn Wilsher :sdwilsh]

Ugh!  I understand how it can be scanned while open - you used open with, which mean exthandler manages the download...

Comment 2

[Ed Lee :Mardak]

Should we not do the scanner if it's an exthandler download? Can we delay exthandler from opening it because the download manager kinda gets the information after-the-fact..

Comment 3

[Shawn Wilsher :sdwilsh]

(In reply to comment #2)
> Should we not do the scanner if it's an exthandler download? Can we delay
> exthandler from opening it because the download manager kinda gets the
> information after-the-fact..
We should still scan - yes.  Can we delay exthandler - not so sure.  biesi?

We could always cancel and restart the download immediately if it is from exthandler.  We already handle the the mimeinfo stuff.  The time that this would suck though would be if it was a non-resumable download because all that progress we made while the dialog was up waiting for user feedback would be lost.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

don't think there's an easy way to do that...