[Webkit-unassigned] [Bug 53600] [GTK] Add DRT support for modal dialogs
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Feb 22 01:53:32 PST 2012
https://bugs.webkit.org/show_bug.cgi?id=53600
--- Comment #14 from Carlos Garcia Campos <cgarcia at igalia.com> 2012-02-22 01:53:32 PST ---
(In reply to comment #13)
> (From update of attachment 126324 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=126324&action=review
> >> Source/WebKit/gtk/webkit/webkitwebview.cpp:2756
> >> + *
> >
> > Signal is true_handled, it should include information about the Return value:
> >
> > * Return value: %TRUE to stop handlers from being invoked for the event or
> > * %FALSE to propagate the event furter
>
> I'd like to be more verbose - %TRUE to stop handlers being invoked and run the modal dialog loop, %FALSE to state that the modal dialog should not be run and propagate the event further.
>
> (Not this exact wording, but something similar.)
Well, this is kind of stantard text we use in every signal that is true_handled.
> >> Tools/GtkLauncher/main.c:134
> >> + gtk_window_set_modal(GTK_WINDOW(window), TRUE);
> >> + return TRUE;
> >
> > Instead of duplicating this in GtkLauncher and DRT, this should be default implementation when the signal is not handled in WebView
>
> When signal is not handled (or FALSE is returned), the current implementation interprets this as a request not to run the modal dialog loop, cancelling any further operations in that direction.
>
> I think it wouldn't be appropriate to force a modal dialog to be shown if the signal is not handled.
You are right, I agree. The same way we don't have a default impl for web-view-rady and close-web-view.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list