Comment 40 for bug 589236

> I've read this a few times but I don't get what you are proposing in the end.

I think what I was proposing was that instead of using "can I get a MIME info object" as a proxy for "there is a default handler" we actually have a way to ask (probably the GNOME registry) "is there a handler for this type" and "is there a handler for this extension?"

I'm fine with this being a followup, I guess.

That might also be cheaper than creating the mime info objects, though I guess .hasDefaultHandler and .lanchDefaultWithFile are not exactly performance-sensitive.

> I don't really understand what you mean.

I mean, just cache a boolean in the mimeinfo for whether it has a default handler and cache the app to use in LaunchDefaultWithFile. But I guess that would in fact take a bit more surgery (esp. for the latter), and not necessarily win us much other than code clarity.... Which is something this code doesn't have anyway, so it's not like this patch is making it worse.

Wolfgang, what worries me about this setup is that if I send an application/pdf file with a .pl extension your browser will happily run it through a perl interpreter with this patch, right? And if a firewall was trying to enforce things based on MIME type, we lose.

Similarly, if I ask for the MIME info for a text/html file with a .cgi extension, and there is no default text/html handler but there _is_ a .cgi handler, we'll come back with a MIME info for text/html and extension .cgi. Not that likely, since we have default handlers for text/html, but if you have a CGI that produces types you do _not_ have default handlers for (e.g. word documents or C++ files or whatever) then this could well affect the "save as" codepath: see the getDefaultExtension function in contentAreaUtils.js. Automated testing coverage for this stuff is spotty; what sort of manual testing has been done here?

Johannes, if you want to help, can you help with testing this patch along the lines described above?