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.
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.
This sounds like a dup of bug 101190, except for the _blank part.
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.
> 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?
>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.
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.
danm, you fixed bug 210560. Was your patch wrong to include targeted links, or is this essentially a dup of bug 101190?
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 ***
> 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".
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.