Bug 17171 - [Gtk] script-confirm and script-prompt signals are not binding-friendly
Summary: [Gtk] script-confirm and script-prompt signals are not binding-friendly
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC All
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk
Depends on:
Blocks: 14141
  Show dependency treegraph
 
Reported: 2008-02-04 03:11 PST by Jan Alonzo
Modified: 2014-04-08 17:45 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Alonzo 2008-02-04 03:11:04 PST
Currently the script-prompt signal requires the callback to return the text (or NULL) value once it's finish/called using one of its pointer argument which is not going to work with the python bindings. Ditto with script-confirm which requires the callback to return the boolean value through its "confirmed" parameter.

There should probably have an API for returning values to WebKit.
Comment 1 Alp Toker 2008-02-08 05:29:53 PST
Good catch.

A user has also requested async API for returning results from JS prompts, which might be worth taking into account when re-designing.
Comment 2 Martin Robinson 2012-02-18 11:55:04 PST
Carlos, do you mind confirming this is not also an issue with the WebKit2 API? If binding infrastructure if good enough where this isn't an issue we can close this bug. If it isn't, we should modify the WebKit2 API to solve this problem.
Comment 3 Carlos Garcia Campos 2012-02-19 08:26:40 PST
WebKit2 works exactly the same way than WebKit1, I don't know what the problem is for bindings. Those methods can't be async.
Comment 4 Zan Dobersek 2012-02-21 07:37:44 PST
I've discussed this with Martin on IRC and come to conclusion that it would be nice to introduce new API for JavaScript dialogs.

Here's an outline of how it might look:

WebKitJSDialog structure
methods:

- webkit_js_dialog_get_dialog_type
returns the type of the dialog, either ALERT, CONFIRM or PROMPT

- webkit_js_dialog_get_message
returns the message of the dialog

- webkit_js_dialog_set_confirmed
only useful on a dialog of type CONFIRM, sets whether the dialog has been confirmed

- webkit_js_dialog_set_response
only useful on a dialog of type PROMPT, sets the response

The WebKitWebView would then carry a signal, something named "script-dialog". The signature of a callback connecting to this signal would look like this:

gboolean callback(WebKitWebView*, WebKitWebFrame*, WebKitJSDialog*, gpointer data)

Some issues of the top of my head:
- the name. If the signal takes the "script-dialog" name, the structure might as well be named WebKitScriptDialog, indicating such dialogs originate from scripts.
- modal dialogs. Should they be included into this API? They're triggered from JavaScript, and their handling is pretty straightforward - handler should return TRUE if it wants to properly display the dialog, FALSE otherwise. Because of that I think they should be, but would like to hear others' opinions.
Comment 5 Martin Robinson 2012-02-21 08:31:16 PST
(In reply to comment #4)

> - modal dialogs. Should they be included into this API? They're triggered from JavaScript, and their handling is pretty straightforward - handler should return TRUE if it wants to properly display the dialog, FALSE otherwise. Because of that I think they should be, but would like to hear others' opinions.

What would the API for modal dialogs look like? If I'm not mistaken the way it works is that a WebView is created in the normal way and then goes into modal dialog mode later.
Comment 6 Zan Dobersek 2012-02-21 10:03:45 PST
(In reply to comment #5)
> (In reply to comment #4)
> 
> > - modal dialogs. Should they be included into this API? They're triggered from JavaScript, and their handling is pretty straightforward - handler should return TRUE if it wants to properly display the dialog, FALSE otherwise. Because of that I think they should be, but would like to hear others' opinions.
> 
> What would the API for modal dialogs look like? If I'm not mistaken the way it works is that a WebView is created in the normal way and then goes into modal dialog mode later.

The only addition would be the MODAL type. If one would then like to actually run the dialog, he would check for the MODAL type, properly set up the web view (setting up transience and modal flag in Gtk+) and return TRUE in the handler.
Comment 7 Carlos Garcia Campos 2012-02-22 10:08:54 PST
I like the the idea of using a single signal for the 3 dialogs, but showModalDialog has nothing to do with these dialogs imo. These are also indeed modal dialogs, and they have to run syncrhonously. With the current api that is pretty clear, because you have to return the result as an out parameter, but passing an object might give the idea that you can ref the object and handle the request later asynchronously, like policy client api. So, I would suggest rename the signal as run-modal-javascript-dialog, and the object passed be a simple boxed type (instead of a full gobject) that we can allocate on the stack so that its scope is the signal emission.
Comment 8 Martin Robinson 2012-02-22 10:29:26 PST
(In reply to comment #7)
> I like the the idea of using a single signal for the 3 dialogs, but showModalDialog has nothing to do with these dialogs imo. 

I feel that it's related, but the process of creating one is so different (create a web view, prepare it, run it as modal) that I'm not sure how cleanly it will be to adapt to this API. In any case, the idea that Zan proposed seems sound to me.

> With the current api that is pretty clear, because you have to return the result as an out parameter, but passing an object might give the idea that you can ref the object and handle the request later asynchronously, like policy client api. 

I think we can solve this problem by just being clear in the documentation.  Note that this is almost precisely the same as the file chooser API that Mario is making, so there is some precedence. 

> So, I would suggest rename the signal as run-modal-javascript-dialog, and the object passed be a simple boxed type (instead of a full gobject) that we can allocate on the stack so that its scope is the signal emission.

I prefer script-dalog or run-dialog.
Comment 9 Carlos Garcia Campos 2012-02-22 11:01:13 PST
(In reply to comment #8)
> (In reply to comment #7)
> > I like the the idea of using a single signal for the 3 dialogs, but showModalDialog has nothing to do with these dialogs imo. 
> 
> I feel that it's related, but the process of creating one is so different (create a web view, prepare it, run it as modal) that I'm not sure how cleanly it will be to adapt to this API. In any case, the idea that Zan proposed seems sound to me.

alert, prompt and confirm are not dialogs to contain a web view, I don't think they are related. modal dialogs are relates to create/ready-to-show/close. It's just a additional step to the process of create a popup window that makes the newly created window run in modal mode.

> > With the current api that is pretty clear, because you have to return the result as an out parameter, but passing an object might give the idea that you can ref the object and handle the request later asynchronously, like policy client api. 
> 
> I think we can solve this problem by just being clear in the documentation.  Note that this is almost precisely the same as the file chooser API that Mario is making, so there is some precedence. 

No, run-file-chooser is async. 

> > So, I would suggest rename the signal as run-modal-javascript-dialog, and the object passed be a simple boxed type (instead of a full gobject) that we can allocate on the stack so that its scope is the signal emission.
> 
> I prefer script-dalog or run-dialog.

run-script-dialog? run usually gives the idea they it will be modal because of gtk_dialog_run()
Comment 10 Zan Dobersek 2012-02-22 12:51:10 PST
Due to the issues revealed in bug #53600 I'd recommend to wait on the decision of providing the MODAL type in this API. As much as possible should be learned from that bug about how to create and handle modal dialogs and only then should the decision be made whether or not modal dialogs can even be handled in an approach as suggested by this API.

Keeping the MODAL type out, there's three types left. In WebKit1, this basically turns three signals into just one. Should the old signals ('script-alert', 'script-confirm' and 'script-alert') eventually become deprecated? Removing is probably not acceptable.

WebKit2 currently carries the same three signals but should probably make that step and remove them in favour of the new one.
Comment 11 Martin Robinson 2012-02-22 13:11:32 PST
(In reply to comment #10)

> Keeping the MODAL type out, there's three types left. In WebKit1, this basically turns three signals into just one. Should the old signals ('script-alert', 'script-confirm' and 'script-alert') eventually become deprecated? Removing is probably not acceptable.
> 
> WebKit2 currently carries the same three signals but should probably make that step and remove them in favour of the new one.

Yeah, I believe the approach you mention of deprecating the WebKit1 signals and just removing the WebKit2 signals is a good one.
Comment 12 Carlos Garcia Campos 2012-02-22 23:50:30 PST
(In reply to comment #10)
> Due to the issues revealed in bug #53600 I'd recommend to wait on the decision of providing the MODAL type in this API. As much as possible should be learned from that bug about how to create and handle modal dialogs and only then should the decision be made whether or not modal dialogs can even be handled in an approach as suggested by this API.

I still think they are different things and should be handled differently, alert, confirm and prompt are modal dialogs too, so having alert, confirm, prompt and modal is indeed confusing. Also, as I said, alert, confirm and prompt are dialogs to show a message, or get user inoput, they are not supposed to show a web view, while window.showModalDialog() is actually a shortcut for window.open with the dialog feature. 

> Keeping the MODAL type out, there's three types left. In WebKit1, this basically turns three signals into just one. Should the old signals ('script-alert', 'script-confirm' and 'script-alert') eventually become deprecated? Removing is probably not acceptable.

Yes.

> WebKit2 currently carries the same three signals but should probably make that step and remove them in favour of the new one.

Yes, in webkit2 we can just remove the 3 signals. Regarding the implementation, I still think we should use a simple opaque boxed type allocated in the stack before emitting the signal.
Comment 13 Martin Robinson 2012-02-23 08:56:05 PST
(In reply to comment #12)

> I still think they are different things and should be handled differently, alert, confirm and prompt are modal dialogs too, so having alert, confirm, prompt and modal is indeed confusing. Also, as I said, alert, confirm and prompt are dialogs to show a message, or get user inoput, they are not supposed to show a web view, while window.showModalDialog() is actually a shortcut for window.open with the dialog feature. 

I don't necessarily disagree that the showModalDialog support should be a separate API, but do note that showModalDialog has a return value and is used for getting user input, much like the prompt API:

https://developer.mozilla.org/en/DOM/window.showModalDialog
Comment 14 Carlos Garcia Campos 2012-02-23 09:22:21 PST
(In reply to comment #13)
> (In reply to comment #12)
> 
> > I still think they are different things and should be handled differently, alert, confirm and prompt are modal dialogs too, so having alert, confirm, prompt and modal is indeed confusing. Also, as I said, alert, confirm and prompt are dialogs to show a message, or get user inoput, they are not supposed to show a web view, while window.showModalDialog() is actually a shortcut for window.open with the dialog feature. 
> 
> I don't necessarily disagree that the showModalDialog support should be a separate API, but do note that showModalDialog has a return value and is used for getting user input, much like the prompt API:
> 
> https://developer.mozilla.org/en/DOM/window.showModalDialog

The fact that you can emulate a prompt dialog with showModalDialog doesn't mean it's the same thing. With showModalDialog you load a new web view in a new toplevel, so you can do whatever you want. Prompt dialogs don't load a web view.
Comment 15 Carlos Garcia Campos 2012-03-05 05:44:58 PST
Wrote a patch to fix this in WebKit2, feel free to use the same approach for WebKit1

https://bugs.webkit.org/show_bug.cgi?id=80271
Comment 16 Martin Robinson 2014-04-08 17:44:58 PDT
WebKit1GTK+ is now gone.