Closed Bug 568253 Opened 10 years ago Closed 7 years ago

A stopped cached plugin is chosen w/o checking that the mime-type matches

Categories

(Core :: Plug-ins, defect)

x86
Windows XP
defect
Not set

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: leeor.aharon+bugzilla, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1064 Safari/532.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 GTB7.0 ( .NET CLR 3.5.30729; .NET4.0E)

Given a page that may embed objects of different plugins, registered with different mime-types, Firefox may choose an incorrect plugin if one of them requested to be kept in memory (NPPVpluginKeepLibraryInMemory). FindStoppedPluginForURL() is using nsPluginInstanceTagList::findStopped() to find a stopped plugin instance, and the whole process is only matching the URL and not the mime-type.

Specifically, my problem is between the Java plugin (used to embed applets, requests to be kept in memory) and my own plugin which does not request to be cached. When my plugin does request to be cached, the process is reversed and my plugin is now called to embed applets.

Trying to understand why the Shockwave plugin works well with the Java plugin, I found that when using an embed tag with a 'src' attribute, the value of the 'src' attribute is used as the URL for the plugin and therefore the nsPluginInstanceTagList::findStopped() function does not match the Java plugin for rendering object of my plugin's type.

The code also hints that the same can be done with objects tags that have a 'data' attribute, but that did not work (nothing was rendered) and Firefox has occasionally crashed in a seemingly unrelated cal to NP_strdup (from JavaScript code, apparently).

Reproducible: Always

Steps to Reproduce:
1. Create an HTML with javascript to "toggle" between two objects of two different plugins, one of which requests to be kept in memory. Use either an object or an embed tag but without a data or src attributes, respectively.
2. Load the page, and toggle between the two object types. Destroying one (a-la innerHTML = "") before creating the new one.

Actual Results:  
If you start with an object from an uncached plugin, you will be able to switch to an object which uses the cached plugin, but not back again.

Expected Results:  
Embedded objects should always be rendered using the plugin which is registered for their specific mime-type. Caching according to URLs should take mime-types into account.
Does this still occur? A lot of this code was refactored and the functions in question no longer exist
Flags: needinfo?(leeor.aharon+bugzilla)
No idea, we have made a change to the application code to always use 'src' attribute in embed tags as a workaround.

I no longer have access to that application for retesting.
Flags: needinfo?(leeor.aharon+bugzilla)
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.