272628 - popups blocked despite whitelisting when dom.popup_maximum is reached

Status: RESOLVED DUPLICATE of bug 260264

(Firefox :: General, defect)

Description

[Robert Brewer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

BACKGROUND
----------
I'm working on a DOM webpage editor called "Tibia", written in Python.
Subversion checkout svn://casadeamor.com/tibia/trunk . The relevant part is
that, in client-side Javascript, I add two event listeners to the HTML document
the user is editing:

doc.addEventListener('click', stop_event, true);
doc.addEventListener('dblclick', edit_element, true);

Notice that both set useCapture to true. stop_event just calls
evt.preventDefault() and evt.stopPropagation(), effectively canceling all
hyperlinks and onclicks on the page.

The edit_element function is the interesting one here, because it eventually
opens a new window by:

var editurl = self.location.href.replace(/[?].*$/, "") + '?view=edit';
selEditWin = window.open(editurl, "tibiaedit", dlgopts);

This all works. Usually.

PROBLEM
-------
While developing Tibia, I serve it on localhost via Apache2 on Win2k (straight
CGI). Usually, this also works. However, about 5% of the time, the double-click
to open my editing window fails--Firefox 1.0 blocks it as a popup. Which would
be fine, except:

1. It doesn't happen every time.
2. "localhost" is in my list of allowed sites. So is "127.0.0.1" and my FQDN,
for good measure.
3. When it is blocked, the option to go ahead and show the page doesn't do anything.

Here's an example URL for the editor itself:
http://localhost/tibia/tibia.tba

The double-click window.open() should therefore reference:
http://localhost/tibia/tibia.tba?view=edit



Reproducible: Sometimes
Steps to Reproduce:
1. Allow localhost for popups.
2. In Javascript, window.open() a localhost URL.
Actual Results:  
Popup window is still blocked.

Expected Results:  
First, allow the popup. If not, at least allow it to be opened from the "click
here for options" menu when blocked.

Comment 1

[OstGote!]

Looks like a dupe of bug 177106 (it is also for FF). Try if the IP address helps
and to open the page via http://127.0.0.1/.

*** This bug has been marked as a duplicate of 177106 ***

Comment 2

[Robert Brewer]

Bah. Same problem with 127.0.0.1.

Comment 3

[Robert Brewer]

Turns out the issue is not about localhost at all. I was running into the
dom.popup_maximum limit. Which leads to two questions/issues:

1. Should dom.popup_maximum apply to whitelisted domains? If not, can we
introduce a separate config entry for that (with an option for unlimited popups)?

2. Once the popup_maximum is reached, Firefox blocks the popup and informs the
user via a menu bar, with the text "click here for options". If the user clicks
that bar, they are offered a menu. The last item in the menu ("Show
'http://domain/page...'") should allow the user to force the display of the
popup; instead, Firefox blocks that popup in turn.

Comment 4

[Justin Finkelstein]

(In reply to comment #1)
> Looks like a dupe of bug 177106 (it is also for FF). Try if the IP address helps
> and to open the page via http://127.0.0.1/.
> 
> *** This bug has been marked as a duplicate of 177106 ***

This bug is NOT a duplicate of 177106, but related to a leak in the window
handling system in FireFox core. Details at:

http://forums.mozillazine.org/viewtopic.php?t=175798&highlight=debug+popup+blocker

Comment 5

[OstGote!]

Sorry for the wrong duplication. The problem with the pref is this bug.

*** This bug has been marked as a duplicate of 260264 ***