whilst i realise that this isn't the bug reporting location for pywebkitgtk, the bug, which is a segfault entirely without warning, is much more likely to be in libwebkit than it is in pywebkitgtk, so i am reporting it here as well as at http://code.google.com/p/pywebkitgtk/issues/detail?id=11
you will need to attempt to log in to the above site, which is a pure AJAX web site with 1.2mb of javascript. i was stunned, amazed and delighted that the demo browser in pywebkitgtk worked on my _smaller_ AJAX-only web site, http://lkcl.net - and quickly moved on to the bigger site, only to be amused at the segfault.
if you use the two test accounts - test and test2 - with passwords of ffffff and tttttt (it could be the other way round) please bear in mind that the site is running LIVE. also bear in mind that people cannot log in twice with the same account.
i downloaded the source from svn as of yesterday. modify pywebkitgtk demobrowser.py in the demo/ directory to instead of starting off the page at gnome somewhere to put http://partyliveonline.com in, instead.

must be run like this:
/var/src/WebKit/Programs/GtkLauncher /var/src/output/index2.html
if you run it as:
cd /var/src
/var/src/WebKit/Programs/GtkLauncher output/index2.html
you don't get a crash (don't know why)
don't look at me and say "that ain't reduced!!!!" - this is the app
that generated it:
from ui import RootPanel, VerticalPanel
from Timer import Timer
from ui import Frame
class index2:
def onModuleLoad(self):
self.panel=VerticalPanel()
RootPanel().add(self.panel)
Timer(1000, self)
def onTimer(self, t):
ad_frame = Frame("./side_ad.html")
self.panel.add(ad_frame)
RootPanel().add(self.panel)
i can't help it if those few lines of code result in 500k of javascript!!!

as you can see from the example python code (which is compiled to javascript
with the pyjamas compiler), what i'm accidentally doing is adding a widget which contains an iframe, and then i'm adding the *same* widget (by mistake) to the root DOM model, twice. it's a mistake on my part, to add the widget twice to the DOM tree but, it causes webkit to segfault.

i think i know what's going on, here.
i believe that the issue could be related to a Document (the one in the frame) having been forcibly deleted. i noticed that the JS bindings have a concept of "mark()ing".
when a frame is removed from the window, it contains a Document which gets forcibly deleted. of course, that doesn't result in any of the bindings getting deleted.
i am _guessing_ that this is why the concept of "mark()" was added to JS bindings.
the alternative is to have a "delete" callback into the binding. when an object has to be forcibly deleted, you must notify each of the bindings that the object is now "gone". it is up to the bindings to then do a "delete" of whatever kind it needs.

alp - sorry. what it does - if you try it on http://partyliveonline.com - is stop the loading process at about 24%. i hit "refresh" several times, waited for about 20 seconds, and no progress was shown.
i unpatched and recompiled, immediately it worked. proceeded to 40%, 58% and loaded the page. takes a lot longer than e.g. on firefox to load that 1.2mb of javascript, but it gets there...
... but not with this patch.

remember - the order of events is as follows:
* view page
* initial frame gets loaded
* timer goes off (creating new thread context)
* timer-inited-thread removes old frame, resulting in destruction of document, including a "Frame"
* destruction of document results in webkit objects being deleted. regardless of current refcount, refcounts are forced to zero.
* WebKitWebFrame contains an object which has been forcibly deleted
* main thread still has "page loading" signals outstanding
* main thread tries to notify user of "page loading" on a WebKitWebFrame where the Frame has been forcibly destroyed, outside of the control of the main thread (by timer-initiated-thread).
* main thread tries to de-reference NULL pointer. segfault.
the fix _really is_ to check that m_frame != NULL. much better would be to copy the style of the JS Bindings, which already have this concept of "mark()ing".
the issue's been solved for javascript bindings, and the code required to fix this issue is there, tried, tested and available for easy adoption and use, to solve the problem.

Created attachment 23568[details]
move g_object_unref() and m_frame = 0 into frameLoaderDestroyed()
no more crashes.
the clue was the two occurrences where m_frame is set to 0.
that, and looking at the qt and wx frame loaders, they do
exactly what this patch does - get rid of the m_frame in
frameLoaderDestroyed() and do nothing - at all - in any of
the detachedFromParentN() functions.

(In reply to comment #14)
> the fix _really is_ to check that m_frame != NULL. much better would be to
> copy the style of the JS Bindings, which already have this concept of
> "mark()ing".
The JavaScript bindings have a concept of marking because JavaScriptCore uses a mark/sweep garbage collector. The collector needs to know which objects are still reachable, so it asks the root set of objects to mark themselves. Each object marks itself, then asks each object it has a reference to to mark itself, which results in recursively marking the entire live JS object graph. WebCore and WebKit are not garbage collected in this respect, they instead use the simpler approach of reference counting. Introducing a "mark" method for refcounted objects doesn't make a lot of sense.

Comment on attachment 23568[details]
move g_object_unref() and m_frame = 0 into frameLoaderDestroyed()
Yes, this is exactly the right fix!
+ notImplemented();
There's no reason to add that call. It's fine for detachedFromParent4() to be empty and no need to call notImplemented().
The change looks fine, but there's no ChangeLog nor test case, so I'm going to say review-. Please submit a new patch with ChangeLog. If this was a platform where layout tests were working well, I'd insist on a test case too, but I don't think GTK is working well with regression tests yet, so I guess we're OK without one.

Comment on attachment 24476[details]
added changelog and removed notImplemented from detachFromParent4
It would be great to get a test case landed if it's possible, in order to ensure that this bug is not re-introduced somewhere down the line (or in other ports).
Other than that, r=me.