User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021122 Chimera/0.6+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021122 Chimera/0.6+ The popup blocking feature seems to have been tweaked in a way that aggressively prohibits all popup windows. So that even a link on a page that should pop up a window in response to actual user input will now be "dead." Reproducible: Always Steps to Reproduce: 1. Load referenced page (http://www.crossroads.net/a). 2. Attempt to click on any "comment" link w/ popup-blocking on. Actual Results: Nothing. Expected Results: Appearance of popup window The code used in the link itself is: <a href="[some URL]" onclick="OpenComments(this.href); return false">Comments: 0</a> The "OpenComments" js function is: function OpenComments (c) { window.open(c, 'comments', 'width=480,height=480,scrollbars=yes,status=yes');} (from Movable Type)

WorksForMe in Chimera 2002112504. Pop-up blocking turned on, window opens as expected.

Confirmed in Chimera 2002112504 on different machine (same OS version). All window.open commands seem to be blocked when pop-up blocking is turned on.

This seems to have disappeared for a while, but is back as of 2002121004

specific example? Does crossroads reproduce again? ->sfraser

saari: yes it does.

that's odd. the test case in comment 0 WFM using 2002.12.10.04 on 10.2.2, when i've got popup blocking enabled.

It seemed to be blocking a legit pop-up on my home banking site too (can't send a URL, as you have to sign on to your account to see it). Is there a white list and black list for what sites get blocked, or is it strickly how the pop-up was initiated?

since chimera is based off of the mozilla1.0 branch, there isn't blacklist or whitelist functionality (iirc).

Per my comments 1 and 2 this seems to be an installation specific bug, i.e. some installations will exhibit the bug consistantly, others will not exhibit it at all, even using the same nightly on the same OS with the same preferences. This bug is always reproducable for me at work on any of the recent nightlies, but is never reproducable for me at home. Same for bug 172649.

So... how does it know which pop-ups to block? Does it just block everything that is not initiated with a click?

Does timing matter? Popups are blocked if they occur within a second of pageload.

This occurs (fails) in Chimera 20030102 for me, but Mozilla of the same vintage allows legit popups

I can reproduce this with Gallery. Go to: http://www.hilander.com/gallery/chimera And try to select 'Rotate Photo' from the dropdown menu. With popup blocking on it will do nothing, but with blocking off it will do what it's supposed to do (give you a popup window that lets you rotate the photo).

Forgot to mention I'm running 2003011304 on 10.2.3, TiBook 667.

The http://www.hilander.com/gallery/chimera test works about 50% of the time for me (randomly) in 2003010304 on a G4 under 10.2.3.

I hadn't tried the http://www.hilander.com/gallery/chimera test many times in a row, but I'm getting periodic success as well (it seems less than 50% but it is working sometimes). Very strange.

I have no in-depth understanding of how popup blocking works, but as I suppose that there will /always/ be some pages which get blocked in error, I would like to propose to make popup blocking "configurable" by the user. I.e., in my opinion it was great if the user could define a "white list" of pages which are allowed to open popups (or, are allowed to be opened /as/ popups). It was also quite useful if there was a key shortcut or a toolbar icon to switch popup blocking on and off without going to the prefs window.

With build 2003012407, pop-up reply windows stopped working for me on http://arstechnica.infopop.net. They work only if pop-up blocking is turned off.

citibankonline.com is broken from this too: it tries to popup a page after you login. I have popup blocking disabled, and it is still broken.

also: I'm running both the 0.7 release and the 2003041205 nightly, on 10.2.5. I've disabled popup blocking in Web Features prefs. I also run privoxy, and have disabled it (though I run thru it). Funny thing: privoxy never blocks its OWN javascript (for running a 'view status' windowlet) for popups, and camino refuses privoxy's popups too, so it's not a privoxy thing. Perhaps the config is stuck? about:config doesn't work :(

followup: I checked my prefs.js, and it looks like user_pref("javascript.enabled") was set to false, even though its setting in 'Web Features' was checked. Maybe somewhere along the line (I tend to grab nightlies every few days) something got disconnected? After quitting, vi-ing the prefs.js file back to true and starting, citibankonline worked and privoxy popups work. Also weird: the prefs.js entry doesn't update until the preferences window is closed. Shouldn't this update instantaneously, in case the browser crashes before the user closes the prefs window?

ok, so this sounds like "user error" somewhere along the way? i'm resolving this as WFM, since there's really no difference from us and mozilla. i've also added a whitelist for sites so we shouldn't get into this situation any more, or at least if we do, users can work around it.

v w4m.