GNOME Bugzilla – Bug 339545
"View" > "Popup Windows" keeps turning itself on
Last modified: 2012-01-29 06:00:58 UTC
Epiphany 2.14.0, Ubuntu Dapper 1. Use "View" > "Popup Windows" to turn off popup windows. 2. Go to <http://random.yahoo.com/bin/ryl>. What should happen: * "View" > "Popup Windows" stays off. What actually happens: * "View" > "Popup Windows" turns itself on again. On further testing it seems that turning off "View" > "Popup Windows" is not the same as turning off "Allow popup windows" in the Preferences. This is counterintuitive, because the other items in the "View" menu don't work the same way. It's also inconsistent with the equivalent menu items in Opera and Safari. It's explained in the status bar as "Show or hide unrequested popup windows from this site", but most people won't notice that. (And that can't be true anyway, because there is no reliable way for a computer program to tell whether two pages are on the same site.)
Note that I've rejected the bug downstream since the current behaviour is a feature and allow to use it by site
I've recently gotten confused by this as well, it would be good if it was clearer that View->Show Popups only applied to the current site.
What about changing "View > Popup Windows" to "View > Blocked Popup Windows", that makes you think "Ah, Ephy _blocked_ a popup window", this should be insensitive if no popup window has been blocked. Right now I can "view popup windows" in bugzilla.gnome.org, there aren't popup windows here but anyway I'm allowed to enable pws. Opinions?
@Diego: It could lead the user into believing there were blocked popups for a site that didn't have any...
That's why I think that a grayed out "Blocked popup windows" would make it clear if we have blocked popups or not. As I said, for example if I'm at bugzilla.gnome.org the option would be grayed out so I can't check or uncheck because there are no popups blocked (or blockeable) in this site.
Created attachment 78980 [details] [review] Makes Popup Windows !sensitive when there are no blocked popups This makes the View > Popup Windows entry sensitive ONLY if there are blocked popups. Since we don't allow popups a priori we can assume that this doesn't hurt. Please comment about this. The logic is (from the patch): /* Make sensitive: * if there are popups blocked, * if they are allowed (so we can select this to block them) and * if they are globally allowed (so we can block for a single site) */ What do you think
Correction: we _do_ allow popups in the default setting. So what happens when popups are allowed in the main preferences and a site shows popups. What do I do to block popups when the menu item is insensitive, because there are no blocked popups?
That's why the menu is sensitive if: * if they are globally allowed (so we can block for a single site) */ That means that no matter they are 0 blocked popups the entry will be sensitive
The change to ephy-statusbar.c is independent, please commit it separately. The changes to ephy-lockdown.[ch] are not necessary, please remove them. That's because in ephy-window.c you can just lookup the action in priv->action_group.
Humm, as always patches slips inside other patches. What a gang. I'll attach an update.
Created attachment 79822 [details] [review] Take two. I have found that we can get to confusing states when taking the settings to extreme cases. But that's also possible without the patch :/. I don't like this setting, it should be different in some way.
Again, the problem is that the "Popup Windows" item doesn't behave consistently with the other items in the "View" menu, and doesn't behave consistently with the equivalent menu item in other Web browsers. Making the menu item usually unavailable won't solve this; it will just make people wonder why it's usually unavailable.
Rejecting this patch, based on comment 12.
So that I'm not just reporting problems without offering solutions ... One option would be to have only a global setting, but for the toggle to both show/hide popup windows requested by the current page *and* set the default behavior for future pages. This would be equivalent to Opera's and Safari's behavior, but with the bonus that it would work for the current page. (Usually you don't realize that you want to change the setting until you're already on a page where you want it to be different). Another option, one preserving the ability to allow popups by domain, would be the Firefox approach -- don't have a menu item, but instead have an explanatory banner whenever a popup window is blocked, and a dialog for managing the domain whitelist.
If we were to give an explanation on blocking a popup window, why not do it via a notification bubble?
Are you thinking of an icon (+ label?) in the statusbar, or of something different?
For the whitelist functionality, someone who's interested could pick up development of the Permissions extension. For the menu option, we could follow Matthew's suggestion and make the popup statusbar icon responsive much like the Adblock one.
See bug #300344. Un-assigning me.
*** Bug 162970 has been marked as a duplicate of this bug. ***
From bug 162970: "From http://mail.gnome.org/archives/epiphany-list/2004-November/msg00048.html "Popups: Sure we do this, but firefox has the discoverability advantage that we need. On the first block we need to show people that we can provide popup blocking and what it looks like when they are blocked from a site." Would popping up a dialog on the first blocked popup (like firefox) be ok?"
We no longer have this menu, and don't have a solution for popup windows either. Whatever we implement in the future will likely not be a menu with this problem.