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

Wed Feb 22 06:30:19 PST 2012

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

--- Comment #21 from Zan Dobersek <zandobersek at gmail.com>  2012-02-22 06:30:19 PST ---
(In reply to comment #20)
> (In reply to comment #19)
> > [...] 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.
> 
> Also, in case it was needed to create that new mainloop, I wonder whether it should be a decision that the client application should make, in the same way it's its responsibility to call to gtk_window_set_modal and gtk_window_set_transient_for (and so WKGTK should care only about emitting the signal)
> 
> Sorry for the two-comments thing

The main loop is required as it serves as the event loop for the web view that is running as the modal dialog. This blocks user input events in the web view from which the dialog originated.

Giving the job of spinning the event loop to the client application may work, but it complicates things for that application implementation-wise. Requesting others' input.

Also please have a look at bug 17171 for modal dialogs in WebKit2Gtk+ - there are some early sketches of what an API for common JavaScript dialogs (alert, confirm, prompt) might look like, and I've proposed about perhaps including modal dialogs in there as well.

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