135263 - Need ability to reparent plugin's widget

Status: RESOLVED FIXED

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

Description

[Peter Lubczynski]

Plugins are currently tried to frames and bug 90268 is about making plugins
survive a reframe. The problem is that the plugin's widget is currently tried to
the frame. When the frame goes away, the widget does too after the plugin
instance is destroyed. This is going to cause a problem during reframe because
as long as the instance is alive, the plugin needs a valid window. This bug is
about supporting reparenting widgets so that we can stash the widget someplace
while our frame goes away.

Looking at the 4.x source, it looks like Waterson did something like this here:
http://warp.mcom.com/webtools/bonsai/cvsblame.cgi?file=ns/cmd/winfe/cxwin.cpp#4038

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

Comment 2

[Chris Waterson]

Marking mozilla-1.0 since this block 90268.

Comment 3

[Peter Lubczynski]

Bug 90268 will probably involve a rewrite of quite a bit of plugin code which I
don't know if there is enough time for Mozilla 1.0.

Comment 4

[saari (gone)]

adding topembed+ as a preemptive measure. Guessing certain embeddors will find
this and want it fixed eventually

Comment 5

[Juan José Mata]

<topembed+ triage> Chris, should this still be assigned to you?  Can we have
somebody in plugins take a look at it?

Comment 6

[Kevin McCluskey (gone)]

Assigning to Peter. WIN32 already supports reparenting of the nsIWidget using
the SetParent method.

Mac and Linux need to have SetParent implemented.

Mac - bug 168117
Linux - bug 168116

Comment 7

[Peter Lubczynski]

per topembed+ triage: topembed-, P2:Future

Comment 8

[Zack Weinberg (:zwol)]

Am I correct in thinking that this bug can be closed once the patch in bug 168117 lands (five years after it was written :-P) ?

Comment 9

[Zack Weinberg (:zwol)]

Bug 168117 has landed.  Closing.  (There's a test case in that bug, if anyone wants to verify.)