[Webkit-unassigned] [Bug 53600] [GTK] Add DRT support for modal dialogs

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=53600





--- Comment #19 from Mario Sanchez Prada <msanchez at igalia.com>  2012-02-22 05:07:14 PST ---
(From update of attachment 126324)
View in context: https://bugs.webkit.org/attachment.cgi?id=126324&action=review

Hi,

I started today working on a similar patch for WebKit2GTK+ and this patch has been extremely helpful so far, so thank you. Just have a doubt related to creating a new mainloop, see my comment below...

> Source/WebKit/gtk/WebCoreSupport/ChromeClientGtk.cpp:206
> +    GMainContext* threadDefaultContext = g_main_context_ref_thread_default();
> +    g_main_context_acquire(threadDefaultContext);
> +
> +    m_modalLoop = g_main_loop_new(threadDefaultContext, FALSE);
> +    g_main_loop_run(m_modalLoop);
> +    g_main_loop_unref(m_modalLoop);
> +    m_modalLoop = 0;
> +
> +    g_main_context_release(threadDefaultContext);
> +    g_main_context_unref(threadDefaultContext);

Is this actually needed? I mean, as far as I can see, calling gtk_window_set_modal(window, TRUE) will already call gtk_grab_add(), which as per documentation does the following:

   "Makes widget the current grabbed widget. This means that interaction with other widgets in the 
    same application is blocked and mouse as well as keyboard events are delivered to this widget."

So, I wonder if it would be enough emitting the signal so the application can decide whether to call to set_transient_for and set_modal (which would do all the modal magic, I think), or if I'm missing something here, and perhaps creating and running a new main loop would be needed after all.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.