[Trac #1105] trapped in gnash (matchbox/sugar/browser bugs?)

[Zarro Boogs per Child]

#1105: trapped in gnash (matchbox/sugar/browser bugs?)
---------------------------+------------------------------------------------
 Reporter:  AlbertCahalan  |        Owner:  rsavoye
     Type:  defect         |       Status:  new    
 Priority:  high           |    Milestone:  Trial-1
Component:  distro         |   Resolution:         
 Keywords:                 |  
---------------------------+------------------------------------------------
Comment (by AlbertCahalan):

 I got trapped in gnash, but I'm not so sure gnash is fully or even mostly
 at fault. (thus the title)

 Things that gnash could do better:

 a. Gnash has no way to leave the preferences dialog. Maybe there is a
 button that didn't fit on the screen.

 b. Maybe gnash should have an exit or quit button too, but Sugar or
 matchbox is supposed to handle that.

 c. A browser-embedded gnash should exit when it is no longer embedded in
 the browser. X might provide a reparenting-related event for this.

 d. A browser-started gnash should exit when the browser dies. You can use
 the prctl() system call with PRCTL_SET_PDEATHSIG to specify a signal. It's
 like SIGCHLD, but backwards and you get to choose the signal. (beware
 though: the "parent" here is the thread that started you) SIGKILL might do
 nicely.

 e. There is a decent likelyhood that gnash is causing the browser to die
 via some sort of failure to correctly implement the browser's plug-in
 interface. I suspect this because I've seen gnash destabilize the browser
 on non-OLPC systems as well. One could argue that the browser should be
 tolerant of badly behaving plug-ins though.

 Other than that though (which is more than I thought, now that I've
 written it all down) it's not gnash:

 f. The browser shouldn't die, even if a plug-in misbehaves. (remember,
 this was NOT an OOM)

 g. Sugar and/or matchbox should be aware of everything connected to the X
 server. The use of DBUS as a substitute for normal window management
 leaves Sugar/matchbox unable to handle the situation. There needs to be a
 way to cause the X server to drop the connection to an app. Old-style
 window managers did this with a "destroy" or "kill" menu and a skull-and-
 crossbones cursor. I think the newer non-Sugar desktop environments
 initially insist on a polite disconnect, then get violent after a timeout
 has passed.

 h. Sugar probably should call kill(-pgrp,SIGKILL) on children which go
 without X server connections for more than a minute. Unfortunately the
 activities are getting reparented to init, and I think they were even
 forked from some dbus thing. Sugar needs that SIGCHLD to know when an
 activity has truly died.

 i. The activity shouldn't get into a half-dead state. AFAIK the activity
 is a Python wrapper around Firefox; some part of the wrapper seems to be
 clueless about things failing. Judging by the zombie process, the wrapper
 doesn't notice when a child process has died.

-- 
Ticket URL: <http://dev.laptop.org/ticket/1105#comment:7>
One Laptop Per Child <http://laptop.org/>