If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED DUPLICATE of bug 101190

Status

SeaMonkey
UI Design
RESOLVED DUPLICATE of bug 101190
14 years ago
13 years ago

People

(Reporter: Blair Bonnett, Assigned: Blake Ross)

Tracking

(Blocks: 1 bug)

Trunk
x86
Windows 95

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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

14 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

14 years ago
This sounds like a dup of bug 101190, except for the _blank part.
(Reporter)

Comment 3

14 years ago
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

14 years ago
> 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?
(Reporter)

Comment 5

14 years ago
>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

14 years ago
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.
Component: General → XP Apps
Product: Firebird → Browser
Summary: Requested popups and 'open in blank' links blocked if page is not finished loading → Can't click target="_blank" links while page is loading
Version: unspecified → Trunk

Comment 7

14 years ago
Created attachment 136843 [details]
testcase

Comment 8

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

Updated

14 years ago
Blocks: 176958
Summary: Can't click target="_blank" links while page is loading → Pop-up blocker blocks clicks on target="_blank" links while page is loading

Comment 9

14 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE

Comment 10

14 years ago
> 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

14 years ago
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.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.