0

I'm struggling with a strange (Webkit-specific?) effect:
When changing the 'position' attribute of a plugin object, my plugin is deleted and immediately replaced by another freshly instanciated.

This means I'm losing all the state of the current plugin and start over with a new one.

I don't know if this is Webkit-specific, since my plugin will only run on our embedded platform.

Here's the code:

<object id="mypluginobject" type="video/myplugin" style="width=800px, height=600px">

In the javascript, I do this:

var myobject = $('mypluginobject');
myobject.style.width = '1280px'; // OK
myobject.style.height= '720px'; // OK
myobject.style.position='fixed'; // myobject disapears and is replaced by a new instance

In the NPAPI code, I can see the NPN_Destroy() called, immediately followed by an NPN_New(), all with the same NPP pointer.

This makes me wonder why this 'position' attribute seem to trigger a complete replacement of my object.

What happens in real-life is that I loose all runtime information, the video stops, and I can't recover. I'm aware that my platform is quite exotic, so there might be side effects of all these:

  • Webkit 322
  • running on Qt 4.7.2
  • and on DirectFB

Any idea?

Gui13
  • 12,993
  • 17
  • 57
  • 104

1 Answers1

1

Unfortunately, this is a pretty standard thing on all browsers. The problem you have is that when you change "position" it changes the container that the object is in; by doing that, you essentially cause the browser to (internally) remove it from the page and then add it back in.

You can cause exactly the same issue by changing "visibility" or "display" on some browsers. "overflow" will pretty universally trigger this as well. It's a similarly bad idea in some cases to set the height and width to smaller than 1px by 1px. Aren't plugins fun?

Avoid these things on the object and its parent elements and you'll be okay. The workaround I use is to always absolute position the plugin itself when I need to move it and then I use jquery to calculate the size and position of a "positioning" element that I do whatever I normally wanted done. It can move, and any time it does (or on an event or timer) I calculate the new position and reposition the floating absolute positioned parent div of the object tag to the new position. It's a bit hackish, particularly if you're wanting to make it fixed, but it's the only way I know to solve the problem.

I guess you could also make your plugin good at restoring its state, of course, so that it doesn't matter when it's removed and readded. =]

taxilian
  • 14,229
  • 4
  • 34
  • 73
  • Sadly, I checked the Webkit code of the version I use, and they *ditch* the data in the saved pointer I give them! So yeah, I'll have to tell the guys using my plugin that if they want the 'fullscreen' function to work, they'll have to use it in a correct position scheme from the start. – Gui13 Jan 08 '13 at 19:10
  • they do, but you could always keep it in global memory with some sort of cleanup mechanism and an instance id or something. There are ways, just not really good or clean ones =] – taxilian Jan 09 '13 at 08:36
  • 2
    Note that those situations (position, display, ...) are slightly different. Changes to `position` *should* not make a difference, but e.g. going `display:none` actually should stop the plugin as *"the element changes from being rendered to not being rendered, or vice versa"* - see [1](http://www.whatwg.org/specs/web-apps/current-work/#the-object-element) and [2](http://www.whatwg.org/specs/web-apps/current-work/#being-rendered). – Georg Fritzsche Jan 14 '13 at 12:48
  • 1
    (By the way, Firefox got more reasonable a while ago when [bug 90268](https://bugzilla.mozilla.org/show_bug.cgi?id=90268) (plugins should withstand a reframe of the object frame) was fixed for Firefox 13.) – Georg Fritzsche Jan 14 '13 at 12:53