problem is partially covered in Bug 217723 (and somewhat in Bug 235350) Situation is really annoying - e.g. it cannot open (in branch) even text files with txt/text extensions - mozilla proposes dialog to choose handler application manually or save, instead opening. One partial reason is buggy implementation of ::GetMimeInfoFromExtension() method in nsOSHelperAppService.cpp - it uses wrong function GuessMimeType(), which isn't getting any info from OS, but relies instead on char* array of sniffer rules, submitted via SetSnifferRules(char *). Which we never done anywhere in mozilla code. I'm preparing patch for that method. But unfortunately this is still palliative - BeOS don't need and don't use extensions for most of files. Thus, proper work of filetyping may be done only on ::GetTypeForFile() level - where we can get real file path, get node from it and ask OS for real mime-type. That's bug 217723 about it, but I will look other things too.

patch will partially reverse bug 327296 checkin. adds helper method BMimeType* nsOSHelperAppService::GuessMimetypeForExtension and fixes nsresult nsOSHelperAppService::GetMimeInfoFromExtension also some style unification

Problem with given patch is that is more or less suitable for sinle file, but with download manager leads to very slow work of last. That's why ineffective lookup for Installed types was removed from code. So no review request for now. Maybe we need global cached OS-mime-databased created at mozilla start once and till app close. Or fix download manager code itself. Don't know what is best atm. Setting dependency on bug https://bugzilla.mozilla.org/show_bug.cgi?id=217723 - as that's proper way to deal with files and extension lookup must be fall-back only case, e.g. for file-systems without metadata

BeOS is dead.