[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 #40 from Martin Robinson <mrobinson at webkit.org>  2012-02-23 08:51:43 PST ---
(In reply to comment #39)

> If the window properties object contains 'dialog' (we should probably find a better name, though) the user should set the modal hint, transient for and run a nested main loop.

It's called 'dialog' on every single port and it's also called 'dialog' in web content. If we choose a different name it should be obvious to people to what bit of the DOM API it corresponds, so I think we should be cautious there.

> But it's always up to the user whether to handle the window feature or not. This is it's clear the difference between window.showModalDialog() and window.open() with dialog fature. 

>From the MDN link I posted above, I believe it's just an instruction to how the window should look.

"The dialog feature removes all icons (restore, minimize, maximize) from the window's titlebar, leaving only the close button. Mozilla 1.2+ and Netscape 7.1 will render the other menu system commands (in FF 1.0 and in NS 7.0x, the command system menu is not identified with the Firefox/NS 7.0x icon on the left end of the titlebar: that's probably a bug. You can access the command system menu with a right-click on the titlebar). Dialog windows are windows which have no minimize system command icon and no maximize/restore down system command icon on the titlebar nor in correspondent menu item in the command system menu. They are said to be dialog because their normal, usual purpose is to only notify info and to be dismissed, closed. On Mac systems, dialog windows have a different window border and they may get turned into a sheet."

In that sense, I think it's somewhat orthogonal to showModalDialog, which just controls whether or not there's an inner main loop while the WebView is showing. showModalDialog has some very specific semantics in the HTML5 spec and the 'dialog' window feature isn't present at all there.

> I don't know objective-c, but it seems to me that mac only handles 'dialog' if the normal create-web-view delegate is not hanlded (because dialog is passed in the features dictionary, so the user should handle it).

The code in question is:

    } else if (features.dialog && [delegate respondsToSelector:@selector(webView:createWebViewModalDialogWithRequest:)]) {
        newWebView = CallUIDelegate(m_webView, @selector(webView:createWebViewModalDialogWithRequest:), nil);
    } else {
        newWebView = CallUIDelegate(m_webView, @selector(webView:createWebViewWithRequest:), nil);
    }

If the window features has 'dialog' and the UIDelegate has a webView:createWebViewModalDialogWithRequest: selector (method), it will be used. Otherwise the webView:createWebViewWithRequest: selector will be used even if 'dialog' is present.

For what it's worth, I don't think we need to add a new signal, just be sure to expose this somehow in the window features.

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