192891 - Changing "data" property of "object" node in JavaScript does nothing.

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P4)

Description

[niall]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212


I am using the OBJECT tag to perform a client side include of HTML (in
preference to IFRAME, as I want it the HTML included inline).  The initial page
load works, however when I change the data property of the OBJECT node using
JavaScript nothing happens.  I have attached a simplified test case (for
image/gif instead of text/html).

Reproducible: Always

Steps to Reproduce:

Comment 1

[niall]

Attachment: Test case.

Demonstrates how changing the "data" attribute of an "OBJECT" node doesn't do
anything.

Comment 2

[Boris Zbarsky [:bzbarsky]]

To plug-ins.

We need to observe changes to "data" and reinstantiate the plugin/image (either
by reframing or within the existing frame).

Comment 3

[Peter Lubczynski]

This is very similar to bug 95548 which is about chagning the TYPE attribute.
The current workaround for this is to remove the old node before attaching the
new one.

Comment 4

[niall]

Peter,

Can you explain the workaround in more detail?  Should I delete the OBJECT node
from the DOM and create a new one?

Comment 5

[Peter Lubczynski]

yes

I think you can also set CSS display:none (which currently destroys the plugin
instance), change attributes as needed, then go back to display:inline, for
example, to restart the plugin. Changing the display type of a plugin has the
nasty side effect of restarting it, see bug 90268.

Comment 6

[niall]

Attachment: Workaround

Demonstrates a workaround

Comment 7

[niall]

The suggested workaround does indeed work - thanks for the suggestion.  BTW -
would the proper fix for this work along the same lines, i.e., recreate the
object node when the data property is changed or would it be better to reload
the object when possible from a performance/memory point of view?

Comment 8

[Peter Lubczynski]

*** Bug 195679 has been marked as a duplicate of this bug. ***

Comment 9

[Peter Weilbacher]

The mentioned workaround does not work for me any more. It does work in 1.7
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7) Gecko/20040618
but not in a current trunk build
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a3) Gecko/20040830

Comment 10

[j.witteveen]

Attachment: new workaround

Comment 11

[j.witteveen]

Comment on attachment 193057 [details]
new workaround

Works with trunk builds too.

Comment 12

[Martijn Wargers (dead)]

*** Bug 212700 has been marked as a duplicate of this bug. ***

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

fixed by bug 1156, although it needs more testing.