769708 - NetUtil.asyncFetch should set channel.contentType explicitly to avoid triggering a cascade

Status: NEW

(Core :: Networking, defect, P5)

Description

[Wladimir Palant]

I have code similar to NetUtil.asyncFetch() in Adblock Plus and realized that calling channel.asyncOpen() to read files can have quite unexpected side-effects. I fixed my code (https://hg.adblockplus.org/adblockplus/rev/c84e4d69b372), doing the same for NetUtil.asyncFetch() might make sense as well. The scenario is the following:

* Some code calls NetUtil.asyncFetch() early in the browser startup process, starts reading a file on disk.
* The call to channel.asyncOpen() ends up in nsFileChannel::MakeFileInputStream() eventually.
* This method calls nsIMIMEService::GetTypeFromFile() that will query nsPluginHost and cause the current list of plugins to be cached there.
* Browser startup process continues and an extension like IE Tab registers a plugin. nsPluginHost already cached the list however and won't return that plugin.
* The user opens Add-ons Manager which will call PluginProvider.buildPluginList() indirectly. It gets the incomplete list of plugins from nsPluginHost and caches it. The Add-ons Manager will not display the IE Tab plugin now even though about:plugins shows it (the latter calls navigator.plugins.refresh() and gets an updated list, too late for Add-ons Manager however that cached the wrong list already).

This kind of side-effect is absolutely not obvious and takes much time to investigate. The simple solution is setting channel.contentType explicitly, this way nsFileChannel doesn't have to query the MIME service and won't trigger this cascade. Obviously, somehow defusing this foot gun for other users of nsFileChannel would be preferable - but I don't see a way right now.

Comment 1

[Boris Zbarsky [:bzbarsky]]

But this won't let consumers find out the type of data, no?

Isn't the real fix for the issue you describe above that "an extension like IE Tab registers a plugin" should update the cached list in the pluginhost?

Comment 2

[Wladimir Palant]

(In reply to Boris Zbarsky (:bz) from comment #1)
> But this won't let consumers find out the type of data, no?

I didn't realize that the consumers even see that channel but you are right - the callback receives it as the third parameter and might be interested in the content type.

> Isn't the real fix for the issue you describe above that "an extension like
> IE Tab registers a plugin" should update the cached list in the pluginhost?

I didn't trace the chain far enough to see whether this is a viable solution. The invalidation of the cached list definitely happens on extension installation/deinstallation, maybe the same operation should be performed after all extensions are initialized - just in case that plugin host already cached something.

Comment 3

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258