[Webkit-unassigned] [Bug 53600] [GTK] Add support for window.runModalDialog

[bugzilla-daemon at webkit.org]

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





--- Comment #25 from Mario Sanchez Prada <msanchez at igalia.com>  2012-02-22 09:29:46 PST ---
(In reply to comment #21)
> [...]
> 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.

Ok I understand, but I still have a concern (maybe an invalid one, though):

If we block on the modal dialog this way, wouldn't we getting more than just an user block regarding to the original window (the opener)? For instance, imagine a new window is opened with showModalDialog() _while_ the original window (the opener) has not still finished rendering... wouldn't this cause the rendering to get blocked (so it never finishes, since the original mainloop won't be dispatching paint events) once the modal dialog is running?

If that was the case, I'm not sure that's what we really want... perhaps it would be better to block user input only (as performed by gtk_grab_add()) instead of blocking the original main loop maybe too much.

> 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.

Yeah, it's probably not a good idea to move that stuff to the application. Not 100% sure either, though.

> 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.

I'll take a look, thanks for the pointer!

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