Comment 52 for bug 968308

I've traced through the WebKitGTK source and identified all paths that lead to webkitWebViewRegisterForIconNotification(). Once the icons database has been disabled these paths all detect this and run away before making this call. By running a WebKitGTK instrumented with fprintf's the only way I can see this function possibly being encountered is if one of these paths happens before the database has been disabled.

The Browser's first invocation of webkit_get_favicon_database(), which is needed in order to disable it, seems like the only place where this could happen in theory, because it creates a background thread that can ultimately invoke webkitWebViewRegisterForIconNotification() after re-joining the main thread. The timing of this re-join is of course variable. In testing I was never able to get this case to actually happen, but I did see some variance in ordering that occurred as a result of the thread join happening at different times.

I've changed the fix in the 4.4 stream to only run for the first WebKitGTK-based Browser since the icons database is shared amongst all instances. I'd like to put the change in 4.3.1, and am reasonably sure that it's not dangerous, but the fact that the crash has been seen in the 4.4 stream is a bit discouraging. Does the frequency of this crash seem at least diminished in 4.4 from what it was in 4.3?