Issue 1:
<webview> elements are able to detect and/or override many of their guest web pages' actions, such as when guest web pages attempt to close themselves and open new windows. However, there is a need for detecting and overriding another type of guest-page event: when an <input type=file> element in a guest page is activated.

For instance, in the Objective-C Apple WebKit framework, the WebUIDelegate method webView:runOpenPanelForFileButtonWithResultListener: can intercept web pages' attempts to display file-input dialogs and allows the surrounding application to display whatever sort of file dialog it wants instead, passing the chosen files back to the web page.

Currently, when an <input type=file> element is activated, Electron will always display the system OS's default file-choosing dialog, with no way for the application to intervene, display an alternate UI, or automatically pass specific files back to the web page. The <webview> element should support overriding file-chooser dialogs.

This issue is somewhat related to Electron issue #749. In particular, NW.js, a project alternative to Electron, somewhat obviates the need for this enhancement by allowing <input type=file> elements' files to be directly set. However, it still has the problem of allowing any guest page to open a file-chooser dialog and modally block the application.

Perhaps this would ideally be implemented similarly to how Electron has implemented overriding popup windows, but it has to also allow the host application to pass back files to waiting guest web pages—for instance, this could be done by implementing the following:

Adding an overridefileuploads attribute to <webview>, similarly to allowpopups. This attribute is off by default. When it is off, attempts by the guest page to open a file-upload dialog will occur normally, as they currently do. When it is on, the <webview> will modally wait for the uploadFiles(filePaths) method, defined below, to be called.

Having <webview>s emit a file-dialog event to <webview>, similarly to new-window. If overidefileupload is on, then this event indicates that its isWaitingForFileUpload() method now returns true.

Adding a isWaitingForFileUpload() method to <webview>. Returns true if the <webview> is waiting for files to be chosen (which can only occur if its overridefileuploads attribute is on). During this mode, the <webview> is frozen and cannot execute commands such as cut(), which will cause it to throw an error (or perhaps it would cancel the file upload, as if the Escape key were pressed while a file-upload dialog was activate).

Adding a uploadFiles(filePaths) method to <webview>. The <webview> must be in waiting-for-files mode. Otherwise, this throws an error (or maybe acts as a no-op, in which case it should return a special value).

Alternatively, something like NW.js's Window's new-win-policy event could be used.

Many of these changes might also be added to webContents, wherever they would make sense.

However, whatever the method with which this functionality is implemented, there will remain a need for overriding or at least disallowing guest pages from opening file-choosing dialogs whenever they want to, just as their ability to open popups or close themselves can also be overridden.

Issue 2:
It could be useful to be able to intercept dialog events from webview (alert, confirm, prompt) to be able to implement our own gui.

Also it is part of chrome webview events

https://developer.chrome.com/apps/tags/webview#event-dialog