227411 - Pop-up blocker blocks clicks on target="_blank" links while page is loading

Status: RESOLVED DUPLICATE of bug 101190

(SeaMonkey :: UI Design, defect)

Description

[Blair Bonnett]

User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.6b) Gecko/20031203 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.6b) Gecko/20031203 Firebird/0.7+

If you request a popup (for instance, a profile window in some forum software)
before the page has finished loading, it is treated as an unrequested popup and
blocked.

The same thing happens if you click on a link which is set to open in a blank
window (i.e. <a href="..." target="_blank">) before the page has finished
loading. However, installing the Tabbrowser Preferences extension
(http://www.intraplanar.net/projects/tabprefs/) seems to have cured this
problem, now that 'blank' links are set to open in a new tab rather than a new
window.

Reproducible: Always

Steps to Reproduce:
1. Make sure popup blocking is turned on in the Web Features section of the
browser options.
2. Find a page which takes a while to load and has a popup link, such as the URL
given above, which is a thread in a forum. The 'Profile' button at the end of
each post is a popup link.
3. Click on the popup link before the page finishes loading.
4. Click on the popup link after the page has finished loading.
Actual Results:  
The requested popup is blocked while the page is loading. After it has finished
loading, it works as expected.

Expected Results:  
Opened the popup as it was a requested one, rather than an unrequested one.

Comment 1

[Ali Ebrahim]

Am confirming this on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b)
Gecko/20031203 Firebird/0.7+. I see this too on other sites as well.

Comment 2

[Jesse Ruderman]

This sounds like a dup of bug 101190, except for the _blank part.

Comment 3

[Blair Bonnett]

I found that bug before posting, but decided to start a new report since this
one appeared to be different. For one, 101190 is not listed specifically for
Firebird. There you got a JS error; this one, you don't. Also, as you said, it
affects target="_blank" links. It obviously treats new windows (i.e. 'blank'
links) as popups, since once you install Tabbrowser Preferences, they open in a
new tab and aren't blocked.

Comment 4

[Jesse Ruderman]

> 101190 is not listed specifically for Firebird

It's a problem in code shared by Firebird and Gecko, so it could be a dup.

> There you got a JS error; this one, you don't.

window.open() sometimes gives a JS error and sometimes doesn't, depending on
what the script does with the return value.

> Also, as you said, [I said that this bug] affects target="_blank" links.

I'm skeptical.  Can you give an example of a site where Firebird's pop-up
blocker blocks a target="_blank" link?

Comment 5

[Blair Bonnett]

>Can you give an example of a site where Firebird's pop-up blocker blocks a
target="_blank" link?

Sure.

First, make sure Tabbrowser Preferences / any similar extension is either
disabled or set to open 'blank' links in a new window.

Then, point your browser to http://www.planegallery.net/forum/forum_posts.asp?TID=44
This is a post in the forums on my website. In my reply (the second and last
post in this thread), there are two links, both 'blank' ones. If you click on
them before the page is finished loading, they are blocked. If you don't find
them in time to click them, refresh using Ctrl-F5, which will clear the cached
version of the page, and give you enough time to do so.

Comment 6

[Jesse Ruderman]

I'm restricting this bug to cover only the link-with-target case.  The
window.open() case is covered by bug 101190.

This regressed between Firebird 0.6 and Firebird 0.6.1:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030516 Mozilla
Firebird/0.6

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030725 Mozilla
Firebird/0.6 

Betcha it was caused by the fix for 210560, "popup windows from form submit are
not blocked", since that involved the target attribute and was checked in during
that time.

Comment 7

[Jesse Ruderman]

Attachment: testcase

Comment 8

[Jesse Ruderman]

danm, you fixed bug 210560.  Was your patch wrong to include targeted links, or
is this essentially a dup of bug 101190?

Comment 9

[Dan M]

This bug's author seems adamant that he's discovered a new problem so I'm
hesitant to close it as a duplicate. But I will, anyway. Maybe I misunderstand,
but I think I'm clear on the problem.

All new windows are blocked while the document is loading; that's how the
blocking code works. I would be astonished to discover it has anything to do
with, specifically, the target "_blank", or a particular front end (Firebird vs
Seamonkey).

With those, I claim extraneous, aspects filtered out, this is exactly bug
101190, or one of its other duplicates, like bug 210121. I mean you could also
write a bug detailing how clicked links fail while a page is loading from a
server in Uzbekistan. No doubt true, but I'd still want to razor down to the
salient core and call such a bug also a duplicate.

This is not to say there isn't a problem here. The popup blocking code should
provide for an override for user clicks, even while the page is loading. It
doesn't. I'm looking at the code right now. But this is covered in that other bug.

(PS Jesse: the special targets named in the patch for bug 210560 are some for
which popup blocking is specifically enforced. _blank is subject to the same
constraints but through a different mechanism. This is all correct behaviour: we
do want _blank to be subject to popup control. A fix for bug 101190 (and this
one) would enter at a different point, and involve click detection.)

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

Comment 10

[Jesse Ruderman]

> This bug's author seems adamant that he's discovered a new problem

That bug 101190 applies to target="_blank" (in addition to window.open) is new
in that it happens in 0.6.1 but not in 0.6.  But since the underlying problem is
the same, this is still a duplicate.  It would be reasonable to change bug
101190's summary to include target="_blank".

Comment 11

[Dan M]

Oh. I should have paid more attention. I agree it is fair to make the
distinction between [window.open in click handler] and [click anchor with new
window target]. It turns out they're the same thing at this level so a fix for
that other bug will also fix this one (I promise!) but it's not as obvious as
all that. I've adjusted 101190's summary.