Closed Bug 176564 Opened 21 years ago Closed 20 years ago
Should be able to manually open a blocked pop-up
I propose the popup blocking icon which appears in the lower left corner of the browser when a website requests a popup should have more functionality than just "unblocking a site". I suggest that clicking the icon will open a menu which will allow me to (a) manually open the popup and (b) a menu item to bring up it's current functionality to unblock a site. To me, this seems more logical than just being able to unblock the site. Say I go to a site which I suspect requires popups to function properly. I have no way of knowing if that's true unless I unblock the site completely.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Popup Blocking Icon Functionality → Should be able to manually open a blocked pop-up
Assignee: blaker → hyatt
*** Bug 192485 has been marked as a duplicate of this bug. ***
I made this screenshot from my duped bug. http://bugzilla.mozilla.org/attachment.cgi?id=113962&action=view All it needs is to remove set pop-up control preferences play sound when pop up is blocked Allow pop ups from snbc.com(or any site) should be renamed to Allow pops from this site. Don't need the submenus for the pop ups. netscape.com>http://wp.netdfasjfjsd.3333333 should just be the http://wp.netdfasjfjsd.3333333
Can someone OS ALL HARDWARE ALL this?
Updated it to only include "makes sense" menus.
*** Bug 201631 has been marked as a duplicate of this bug. ***
This is something that would be useful to me. I am fine with the dialog box that pops up already, I would just add a button called "view popup" to the right of "unblock site". The view popup button will not save any state and will only show the popups from the site this time.
See also bug 198846, same bug for Seamonkey.
*** Bug 218340 has been marked as a duplicate of this bug. ***
*** Bug 220185 has been marked as a duplicate of this bug. ***
In Bug 220185, I suggested opening the pop-up by simply double clicking on the URL. The reason I recommended a double click was because it would require the least mouse movement (thus it would be the quickest). So... there have been several ways suggested in this bug report to launch the new window. 1. double click on the URL 2. a context menu (brought up by a right click) 3. a button that says "view popup" From a user interface design perspective, if we use a right click context menu, it might prove best to also have the button "view popup." In general, the context menu is meant to reveal options that are available elsewhere (such as a menu or button). However, there is also another area of concern - as you know, window.open carries with it a number of properties from the window handle to the height and width of the pop-up. The question is, should this feature be designed to remember those properties and use them in launching the new window? ->Recommend adding "polish" keyword
I think often popups would need to be "executed" rather than just opened for the same reason mentioned that window.open would carry with it a whole host of options for setting the new window state. - rmjb
In reply to Comment #12 I think this issue deals more with the ability to see what the pop-up was all about than it does with actually using it on a regular basis to open pop-ups. However, I do agree that you cannot replicate all of the processes that happen to that pop-up such as writing to the window. However, I do think it is possible to capture the data called by the window.open command and use just that little bit in creating the pop-up. Honestly, I'm not sure which is better: Opening the pop-up URL in just a plain old new window or opening the pop-up URL as specified in the window.open command. Both methods could be potentially useful to the user depending on why they want to view the pop-up/URL.
Longhorn's version of Internet Explorer appears to have this feature: http://mpt.phrasewise.com/2003/10/29#a472
Doesn't the pop-up blocker *already* unblock a window if you click the link again? first click: nothing happens, just the notification icon appears second click: window openes without globally unblocking the site
The bug is more along the lines of being able to see popups that happen automatically, for example on page load, that you can't manually re-trigger. - rmjb
> Doesn't the pop-up blocker *already* unblock a window if you click the link > again? That is incorrect. If a link (not the destination, but the link itself) triggers a pop-up and Firebird blocks it, that's a bug.
> If a link (not the destination, but the link itself) > triggers a pop-up and Firebird blocks it, that's a bug. ack, at least it shouldn't block manual triggered windows ;)
I noticed an error in my comment (Comment #11) So, let me restate: Points #1 and #3 apply to the window that comes up whenever you doubleclick on the pop-up icon in the lower, left corner. 1. double click on the URL 3. a button that says "view popup" Point #2 refers to the icon in the lower, left corner. (This is what this bug report is all about). 2. a context menu (brought up by a right click) I think I need to file a separate enhancement report for poings #1 and #3.
As far as I tell if we wanted to get the popup to open in it's own little window (i.e. exactly how it would have if it hadn't been blocked) then the DOMPopupBlocked event will need to be updated to pass the parameters of window.open to the front-end. On the other hard, if we just wanted the ability to open blocked popups in a new tab all you'd need are a few minor changes to browser.xml so that it stores evt.popupWindowURI, then add something to the Page Report UI to allow that URI to be opened (I've just played around with this and it wasn't too hard to get something primitive working). So if Firebird wants the full-blown open-popups-in-their-own-little-window then we probably need to file a DOM:Events bug (that blocks this one) to request that window.open parameters get attached to the blocked popup event. Unfortunately though, at the moment I think both of these methods are blocked by Bug 212460, so until that gets fixed neither of these options are possible (opening some popups will work, but most won't).
Bug 198846, the same bug for Seamonkey, was fixed last week. Part of the patch was to xpfe.
*** Bug 239611 has been marked as a duplicate of this bug. ***
+ing... should not be too difficult.
Flags: blocking1.0? → blocking1.0+
so can this bug get sorted now that same bug in seamonkey has recently been fixed? http://bugzilla.mozilla.org/show_bug.cgi?id=198846
20 years ago
Assignee: hyatt → bugs
Priority: -- → P4
This can now be done by clicking the blocked popup icon in the status toolbar and selecting Show "url.." see bug 251051 for improvemnet of the wording there. marking fixed in conjuction with the status whiteboard.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Currently using 1.0PR (Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10) And when I go to http://www.cnn.com the information bar tells me there's a pop-up blocked, click for options. When I click and choose to open pop-up I get a pop-up window with the title as Advertisement and the window is blank. When I click and choose to allow pop-ups from www.cnn.com and refresh the page I get a pop-up in a smaller window asking me what edition of CNN I'd like (local or International). This is the expected behaviour. To test this go to http://www.cnn.com with a fresh profile and try it out. What ever is executing the blocked pop-up code isn't doing it correctly. - rmjb
(In reply to comment #26) > Currently using 1.0PR (Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) > Gecko/20040913 Firefox/0.10) And when I go to http://www.cnn.com the information > bar tells me there's a pop-up blocked, click for options. > > When I click and choose to open pop-up I get a pop-up window with the title as > Advertisement and the window is blank. When I click and choose to allow pop-ups > from www.cnn.com and refresh the page I get a pop-up in a smaller window asking > me what edition of CNN I'd like (local or International). This is the expected > behaviour. > > To test this go to http://www.cnn.com with a fresh profile and try it out. > > What ever is executing the blocked pop-up code isn't doing it correctly. > > - rmjb > I see similar behaviour in the 20041001 build of the same (with slight differences due to how the CNN page behaves whether I allow or deny its cookies for 4 different "owning sites".) I'll see tomorrow (or whenever it's released) how the upcoming FF 1.0 BC1 handles it.
You need to log in before you can comment on or make changes to this bug.