Open Bug 497081 Opened 15 years ago Updated 2 years ago

Mimetype/filetype/content type association handling subsystem behavior becomes buggy after repeated downloading of files

Categories

(Firefox :: File Handling, defect)

x86
Windows 7
defect

Tracking

()

Tracking Status
status2.0 --- ?

People

(Reporter: aarskever, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729)

I frequently download files using services like iFile.it, and after a few dozen or so downloads, the content type handler starts to forget which behavior is associated with which filetype. (This also occurs when downloading .torrent files from sites like demonoid.com) On every download it asks what should be done with the file (open/save), with the "remember" tick box greyed out.
After deleting the mimetypes.rdf file from the config, this will work again for a while, but within a few days this starts all over again. The problem is not limited to win7, as it also happens on winXP (sp2+3)
iFile has a sort of captcha system that requires you to request a link first, after which it will give you a link to the file, so it might have something to do with ff not being able to grab some sort of information that it needs in order to ascertain the mimetype, but I really haven't a clue what I'm talking about, so..
An

Reproducible: Always

Steps to Reproduce:
1.delete mimetypes file
2.save a behavior for a file type (say, .torrent)
3.download any .torrent files from demonoid.com (FF always refuses to remember/apply the settings to files downloaded from this site), or multiple files from iFile.
4. $profit? (sorry)
Actual Results:  
I get the "what do you want to do with this file" dialog

Expected Results:  
it should have remembered what to do with the given file type, and automatically opened it with uTorrent (or saved it to disk)
Unless you post a URL for such a file i can't see a bug here.
The extension of a file doesn't matter for a browser, that means ".torrent" doesn't mean anything. 

Which content-type is send for the file and is there an content-disposition:attachment header ?

For content-disposition:attachment, application/octet-stream or text/plain from an apache server (content-sniffing) the checkbox is disabled by design.
The bug is old, but it's alive.
rutracker.org - but it's in russian and you need to register first. But the bug is 100% reproducible.
Similar to bug 234243?

If we could get a reproducible testcase, that'd be great.
Status: UNCONFIRMED → NEW
status2.0: --- → ?
Ever confirmed: true
Product: Firefox → Core
QA Contact: file.handling → file-handling
Product: Core → Firefox
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.