Comment 4 for bug 1182603

I tried to implement such a while-loop even if it is CPU intensive but without success. As soon as I block the current thread with a while-loop the toolbar editor dialog gets unresponsive. I even tried to run g_main_context_iteration of the current active GMainContext to keep the event dispatcher running (I hope it is the right way to do - no idea) but the result was the same.

The difference of the toolbar dialog might be that it creates a GtkDialog and runs gtk_dialog_run which sets the GtkDialog modal, starts its own main loop and waits for this main loop to be quitted like I do in CookieSecurityManager. As far as I understood Glib and GTK+, the problem is that GtkDialog has higher priority to input events as it modal and waits for its GMainLoop to quit. But in the meantime the cookie infobar GMainLoop is created and started and has higher priority because it was the latest one started but it will never be quitted as it will no get any event because GtkDialog is being modal. It's a dead end.

It is not the solution I want but making the toolbar editor window not modal would be the easiest one. I could also imagine that making GtkDialog modal but calling gtk_dialog_run() could help. The preferences window of Midori or my extension did not block but are modal. That means you have to close these windows before you can click the info bar but they do not block or make Midori unresponsive.