See upcoming testcase. It contains this: <embed height="380" SRC="htttdgfhdhgp://fd" width="600"> It uses a bogus url. But with current trunk builds, it is loading a plugin. It used to load the Zylom Games Player plugin for me, so I thought, maybe my system setup is weird. But after I removed that plugin in "C:\Documents and Settings\All Users\Application Data\Zylom\ZylomGamesPlayer", the testcase loaded the Java plugin. With branch builds no plugin is loaded, so this seems like a bug to me. This regressed between 2005-10-28 and 2005-10-31: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-10-28+05&maxdate=2005-10-31+06&cvsroot=%2Fcvsroot I think it's a regression from bug 309529.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/src/nsObjectLoadingContent.cpp&rev=1.36#1338 > if (host && > NS_SUCCEEDED(host->IsPluginEnabledForExtension(ext.get(), typeFromExt))) { > typeToUse = typeFromExt; > } If the URL has no extension at all, |IsPluginEnabledForExtension| which in turn calls |FindPluginEnabledForExtension| will return a bogus MIME type. We should check whether |ext| is empty. FYI, |TrySetUpPluginInstance| already performs a similar check before calling |FindPluginEnabledForExtension|. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp&rev=1.564#3798 > if (fileExtension.IsEmpty() || > !(pluginTag = FindPluginEnabledForExtension(fileExtension.get(), > mimetype))) { > return NS_ERROR_FAILURE; > }

Looks like this affects all platforms. Bug 389960 is on Linux. (Changing OS from Windows XP to All)

+ if (aTypeHint.IsEmpty()) { + rv = NS_ERROR_NOT_AVAILABLE; + return NS_OK; + } Isn't that weird? (it looks weird to me)

Comment on attachment 275196 [details] [diff] [review] patch r+sr=bzbarsky, but could we file a bug on plugins to return error in this case instead of handing back random data? Martijn, there's an nsAutoFallback on the stack that's watching the value of rv and doing some work to fall back if the function returns when rv is failure.

Comment on attachment 275196 [details] [diff] [review] patch Ok, thanks for the explanation, Boris.

Comment on attachment 275196 [details] [diff] [review] patch this is wanted-1.9 and therefore autoapproved. I'll check it in probably tomorrow.

Bug 391113 filed on plugins Checking in nsObjectLoadingContent.cpp; /cvsroot/mozilla/content/base/src/nsObjectLoadingContent.cpp,v <-- nsObjectLoadingContent.cpp new revision: 1.57; previous revision: 1.56 done

Thanks, verified fixed, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007080705 Minefield/3.0a8pre