Thus if you have a plugin that can handle ActiveX Object, that plugin will be created and initialize wmp control instead. If you define DISABLE_ACTIVEX_TYPE_CONVERSION_MPLAYER2, for Windows Media player object it will not try to map it to "application/x-mplayer2" plugin. Unmapped ActiveX Object will have service type "application/x-oleobject". If you don't make any #defs, it should behave pretty much the same as before, except:
APPLICATION X MPLAYER2 SAFARI PATCH
I have made some tentative changes and will upload the patch later. While usually it's application/x-oleobject in most other places I see. If we could add some #ifdef to turn on/off whether we want to do th mapping, that would be great.Īnother smaller problem I see is, it maps unknown ActiveX class id to type : application/x-activex-handler. e.g., the URL given works well in FireFox with the npActiveX.dll plugin downloaded from. If we just map the type to application/x-oleobject and let the Activex plugin handle it, we may have better rendering.
There has been some ActiveX plugin which could handle the ActiveX object better. However, this may not be always the way users wanted.
In RenderPartObject.cpp, it will map the class id to service type: application/x-mplayer2 then try to load the media player plugin to handle it. The current WebKit converts OBJECT tag with well-known classids (e.g., Windows Media Player) to corresponding plugin-ins.
0 kommentar(er)
