GNOME Bugzilla – Bug 603192
Display script alerts in a GtkInfoBar instead of popup window
Last modified: 2016-11-26 13:38:10 UTC
Popup dialogs mostly occur when website scripts are using the alert(), confirm() or prompt() methods. That happens quite often and is especially irritating when they force a switch away from the tab you are currently working in. It would be better if such dialogs could be transient to the relevant tab rather than to the window as a whole. That is not possible when using a dialog window, but it could be done by using GtkInfoBar instead. Each tab would then have its own infobar, of course only visible when a dialog is needed, laid out something like this: GtkVBox |- GtkInfoBar |- GtkScrolledWindow |- WebKitWebView The webpage can be made untouchable until the dialog is dismissed, like a modal dialog would block the webpage. There can be a discrete animation to draw attention from the webpage towards the info bar. It would have to be stated that the infobar content originates from the website, by showing a caption like "Message from the website". This has the advantage that many tabs can show their dialog at the same time, since the dialogs are located within each tab. So there is no need to brutally move focus to another tab when it needs to present an alert. Another advantage is that a (completely or seemingly) endless loop of alerts couldn't block the whole browser window, only the specific tab. Although it should ideally be possible already to break out from a loop of alerts. The layout may seem odd at first, but it could work nicely and there are no rules on how alerts must be presented. It might be good to make it optional though.
I agree in general with doing this for all dialogs attached to a web view, but it needs some previous refactoring work since at the moment several places in the code assume that the children of the notebook are directly the EphyEmbed's, which wouldn't necessarily be the case here. Basically, AFAICT, we need a layer on top of the embeds that can hold any number of infobars, or other widgets, on top of the actual embed.
I think also messages from the engine like "hostname could not be reolved" should be moved to a dedicated notification area. They now appear as if they were a webpage, so it could be interpreted as if you actually reached the host and now they are presenting this message for some reason.
I think -- this must be default behavior (not a option). in current time (2016 year) -- only GNOME Web Browser (epiphany) exposed to attake of infinite-loop-of-popup-dialog :-)
(In reply to Andrej Antonov from comment #3) > I think -- this must be default behavior (not a option). Yeah, we're not going to add an option for this... either we can use info bars (seems like a good idea to me) or we use dialogs; there's no reason for this to be configurable. > in current time (2016 year) -- only GNOME Web Browser (epiphany) exposed to > attake of infinite-loop-of-popup-dialog :-) It's a separate issue. We don't need to remove script dialogs to fix that.
I don't think using a GtkInfoBar will work well here. Websites expect to have more space to display messages; a GtkInfoBar has very little real estate available. Of course the infinite popup dialog bug must be fixed, but that is tracked as https://bugs.webkit.org/show_bug.cgi?id=164853.