126224 - (NY Times) Web sites can create pop-up windows using img onload even if unrequested window is blocked (nytimes, image, popup)

Status: VERIFIED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[TT]

Under Preferences->Advanced->Scripts and Windows, I have the following three
unchecked: "Open unrequested windows", "Move or resize existing windows", and
"Raise or lower windows".  This effectively eliminates pop-up windows (although
it would be nice if I could control this feature on a per-site basis, but that's
another story).

Somehow, NYTIMES.COM has managed to get around this.  It dosn't always happen,
but when I visit the site, or click on a link to read a story, low-and-behold, a
pop-up window appears with an ad!

Comment 1

[Phil Schwartau]

Browser, not engine. Reassigning to Preferences and cc'ing Mitch, rginda.
Compare similar-sounding bug 123647,

  "Popup window appears even when "open unrequested windows" is unchecked"

although that is at a different site -

Comment 2

[Eric Vaandering (no email)]

I see this on linux too

Comment 3

[Samir Gehani]

CC'ing Doron.

Comment 4

[Mitchell Stoltz (not reading bugmail)]

Did anyone capture the offending script? 123647 was caused by an onLoad in an
image tag; we don't check for that. Is this the same thing?

BTW, I'll take this bug, unless someone wants to fix it right away.

Comment 5

[Markus Långström]

*** Bug 127555 has been marked as a duplicate of this bug. ***

Comment 6

[rafeco]

I captured the script at:

http://rc3.org/clips/orbitz_popunder_js.txt

Comment 7

[Robert Ginda]

Attachment: patch adds dom.disable_open_click_delay pref

this patch lets users set dom.disable_open_click_delay to the max acceptable
delay between a mouse click and a window open.	dom.disable_open_click_delay is
a time in milliseconds.

Comment 8

[Robert Ginda]

Attachment: testcase

Comment 9

[Robert Ginda]

Attachment: patch without printf and commented out code

Comment 10

[Robert Ginda]

Mitch, would you like to drive this one into the tree again?

Comment 11

[Robert Ginda]

jst, got time for a sr?

Comment 12

[Matthias Versen [:Matti]]

*** Bug 127573 has been marked as a duplicate of this bug. ***

Comment 13

[Olav Vitters]

*** Bug 123647 has been marked as a duplicate of this bug. ***

Comment 14

[Matthias Versen [:Matti]]

*** Bug 128974 has been marked as a duplicate of this bug. ***

Comment 15

[Johnny Stenback (:jst)]

Comment on attachment 71225 [details] [diff] [review]
patch without printf and commented out code

- Replace all 4 space indentation with 2 space indentation.

- s/PRInt64/PRTime/ on the whole diff

sr=jst

Comment 16

[Mitchell Stoltz (not reading bugmail)]

Comment on attachment 71225 [details] [diff] [review]
patch without printf and commented out code

r=mstoltz. Good idea! I'll see about getting this into Moz 1.0.

Comment 17

[Asa Dotzler [:asa]]

Comment on attachment 71225 [details] [diff] [review]
patch without printf and commented out code

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 18

[Robert Ginda]

Actually, it occurs to me now that PR_IntervalNow has no units.  We should
probably use PR_Now instead, and divide |delta| by 1000 to get to milliseconds.
 Mitch, do you want to own the patch from here, or should I work up a new version?

Comment 19

[Robert Ginda]

Attachment: updated patch

spacing fixed, initialization fixed to use LL_ZERO instead of literal 0,
PR_IntervalNow changed to PR_Now, PRInt64 changed to PRTime (the rest of the
file uses PRInt64, btw.)

Comment 20

[Robert Ginda]

jst, if you'll give the latest patch your blessing, I'll check it in when the
tree opens.

Comment 21

[Johnny Stenback (:jst)]

Comment on attachment 73206 [details] [diff] [review]
updated patch

sr=jst

Comment 22

[Mitchell Stoltz (not reading bugmail)]

Comment on attachment 73206 [details] [diff] [review]
updated patch

Thanks for taking the initiative here, Rob. You know this stuff better than me.
r=mstoltz. I'm assuming it's safe to use a PRTime as the seocnd parameter to
LL_L2I

on all platforms - is that safe? Is PRTime always a long long?

Comment 23

[Johnny Stenback (:jst)]

PRTime is typedef'ed to PRInt64, so on most platforms that would be a long long,
and yes, it should always be safe to use with the LL* macros.

Comment 24

[Robert Ginda]

Checked in to trunk.

Comment 25

[Jeremy M. Dolan]

On pages with a lot of images (news.bbc has over 40, for example), for a modem
user, a solution based on time could be troublesome. It would need delicate
fine-tuning, and still could be off. There's no easy way to do the clean
solution and disable onload=window.open in any element? Also, the patch doesn't
seem to add the new pref automatically when you disable "open unrequested
windows" in scripts & windows... should it?

Comment 26

[Robert Ginda]

Asa gave me a verbal a= to check in to the 0.9.9 branch, so I just checked in
there too.

Jeremy:  I don't think this will be a problem for slow loading pages.  The time
we measure is between the mouse click and the window.open request.  Even on slow
pages that time should be very small.  As far as the UI goes, someone else will
have to knock one together, please file a seperate bug.

Comment 27

[Robert Ginda]

Under "What's New In This Release", we should add something like...

      <li>
        It is now possible to disable the JavaScript <tt>window.open()</tt>
        method when it is not called as a result of a mouse click.  When the
        <tt>dom.disable_open_click_delay</tt> pref is set to a nonzero number,
        window.open will fail when called more than that number of milliseconds
        after a mouse click. Setting this pref (instructions
        <a href="http://www.mozilla.org/releases/mozilla0.9.9/#setprefs">here</a>)
        should turn off pop-up and pop-under ads that use the <tt>onload</tt>
        handler of <tt>&lt;img&gt;</tt> tags to work around our
        <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=92955">previous</a>
        <tt>window.open()</tt> filter.  

        (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=126224">Bug
92955</a>)<br>
        <br>
        <tt>user_pref("dom.disable_open_click_delay", 1000);</tt>

Comment 28

[Sean Harding]

Why is this implemented as a seperate preference from the "Allow scripts to open
unrequested windows" pref already implemented? In my mind, that checkbox should
turn this feature on and off as well. From a user perspective, they do exactly
the same thing -- stop popups. So, while it may be implemented as such, this bug
doesn't introduce new functionality for the user. It corrects a bug with the
existing functionality. And I strongly believe that there should not need to be
a seperate UI pref for this as suggested in Comment #26. That's going to be very
confusing for users.

Comment 29

[Robert Ginda]

This is new functionality, it does *not* correct a bug in the previous
implementation.  The previous implementation which "prevents window.open from
working during onload, onunload, and timeouts" still exists and has *no* bugs. 
The fact that our prefs UI mis-represents, or glosses over the details is of no
concern to me.  File a new bug to bring the UI in line with this new
functionality.  I don't own that UI and have no personal interest in doing that
work myself.  UI discussion does not belong on this bug.

I'm sure if y'all stop whining here and just file a new bug for the UI, someone
will step up and do the work.

Comment 30

[Tom Mraz]

*** Bug 120413 has been marked as a duplicate of this bug. ***

Comment 31

[Jason Bassford]

I agree with Robert.  If the wording of the Pref is "Allow scripts to open
unrequested windows," and having this checked does not prevent some sites from
opening an unrequested window - as here - then it's a bug.

You can look at this two ways.  It's a bug with the UI or it's a bug with the
Mozilla code not implicitly linking this current bug into the existing UI. 
Which is less confusing?  I would think it would be less confusing to keep the
existing UI and link this bug into it so that there's no need for a separate Pref...

Comment 32

[Chris Casciano]

Your average web surfer is dumb to the ways of the web developer. They don't
know the difference between a window.open() in a body onload, an image onload,
one that's just sitting out there to be executed sans event. To them there is no
difference. The behavior of these, however, is the same and its this bahavior
that they want to disable.

If you support the opposite view then every time a sneaky developer finds a way
of opening an unrequested popup then you'd have to add a new option in the UI.
Can you imagine:

- Disable Unrequested Popups from body.onload
- Disable Unrequested Popups from image.onload
- Disable Unrequested Popups from iframes
- Disable Unrequested Popups from js/DOM inserted script elements
- Disable Unrequested Popups from onmouseover
- Disable Unrequested Popups from onmouseout

I suggest that any developer action that causes the behavior of an "unrequested
popup" be grouped under this singular preference. Call this whining if you'd
like, but I think this bug needs to be reopened and dealt with.

Comment 33

[Robert Ginda]

I've filed bug 132031 to deal with the UI.  Maybe one of you wants to submit a
patch, or something.

Comment 34

[Vadim Berezniker]

*** Bug 133871 has been marked as a duplicate of this bug. ***

Comment 35

[Vadim Berezniker]

*** Bug 139318 has been marked as a duplicate of this bug. ***

Comment 36

[Eric Vaandering (no email)]

I can't get this workaround to work on RC1 and nytimes.com

I've tried setting the value to 1000,250,100,10, and 1. I would assume faster
machines would use shorter times.

Comment 37

[Andrei Leo]

Bug 126224 fixes just one method of opening unrequested popups.
It's easy to implement others.
For example, I can open popup from document.body.onmousemove handler.
Event triggers when user just moves the mouse in the window.
It means in 99.99% - popup will come up.

I think it should be reopened with more general summary.

Comment 38

[Alfonso Martinez]

*** Bug 144481 has been marked as a duplicate of this bug. ***

Comment 39

[Phil Schwartau]

*** Bug 145628 has been marked as a duplicate of this bug. ***

Comment 40

[Sander]

*** Bug 146480 has been marked as a duplicate of this bug. ***

Comment 41

[Sander]

*** Bug 147184 has been marked as a duplicate of this bug. ***

Comment 42

[Jesse Ruderman]

*** Bug 153362 has been marked as a duplicate of this bug. ***

Comment 43

[Alfonso Martinez]

*** Bug 153778 has been marked as a duplicate of this bug. ***

Comment 44

[Jesse Ruderman]

*** Bug 154270 has been marked as a duplicate of this bug. ***

Comment 45

[Matthias Versen [:Matti]]

*** Bug 154476 has been marked as a duplicate of this bug. ***

Comment 46

[Sander]

*** Bug 155134 has been marked as a duplicate of this bug. ***

Comment 47

[Boris Zbarsky [:bzbarsky]]

*** Bug 155545 has been marked as a duplicate of this bug. ***

Comment 48

[Boris Zbarsky [:bzbarsky]]

*** Bug 155901 has been marked as a duplicate of this bug. ***

Comment 49

[Jesse Ruderman]

*** Bug 146570 has been marked as a duplicate of this bug. ***

Comment 50

[Jesse Ruderman]

*** Bug 154988 has been marked as a duplicate of this bug. ***

Comment 51

[Alfonso Martinez]

*** Bug 156673 has been marked as a duplicate of this bug. ***

Comment 52

[Robert Ginda]

*** Bug 157980 has been marked as a duplicate of this bug. ***

Comment 53

[Jamie Zawinski]

Why was this implemented as a timeout?  It seems to me that, no matter *how*
much time has passed, if the window-creation action is not occurring as a direct
result of a mouse click, then no windows should be created.

In other words, windows should be creatable by *inclusion*: when and only when:

  - I've selected "File / New / Navigator"
  - I've clicked the middle button on a HREF
  - I've selected "Open in New Window" from the context menu
  - we're inside the scope of an onClick handler of an HREF that was
    loaded as the direct result of a mouse click.

Relying on timeouts suggests that you've lost track of how you got where you
are, and that's the actual bug that should be fixed.  Right?

Comment 54

[Wesha]

*** Bug 153798 has been marked as a duplicate of this bug. ***

Comment 55

[Wesha]

*** Bug 158462 has been marked as a duplicate of this bug. ***

Comment 56

[Wesha]

*** Bug 158536 has been marked as a duplicate of this bug. ***

Comment 57

[Wesha]

*** Bug 127757 has been marked as a duplicate of this bug. ***

Comment 58

[Wesha]

*** Bug 126905 has been marked as a duplicate of this bug. ***

Comment 59

[Wesha]

We keep getting bugs describing the case every day. I don't see how come we have
this RESOLVED FIXED. Maybe WONTFIX, but not FIXED!

I'll keep an eye on the user input for the next week, and will reopen next
Sunday. If anybody objects, please reply.

Comment 60

[David G King]

I don't see any point in waiting another week (with all due respect). I count 27
dups.....with most of them happening after this was "fixed". So, I'm reopening
this now as the existing UI pref should take care of this problem.

Comment 61

[Mike Young]

I think JWZ is right in comment #53 

we should not keep developing workarounds for the ways web developers bombard us
with pop-ups. Stopping them alltogehter unless called from the interface or from
a direct onclick handler (or the call to a function as the target of a href) is
the only way to ensure that we don't have to come back to the drawing board
every time.  If we have a pref that disables unrequested windows, lets go all
the way and disable unrequested windows... It should be much easier to create an
inclusive list of "requested" windows than create a list of all the possible
ways something could be unrequested.

Comment 62

[Rob McMillin]

At risk of being one of those dorks who writes "me too" posts, I also concur
with JWZ's comment 53.

Comment 63

[tom.williams]

I concur with Mike Young's comments above.  I opened one of the "dupe" bug 
reports regarding this issue and I think Mike Young's comments really "hit the 
nail on the head".

Peace....

Tom

Comment 64

[Robert Ginda]

This bug was marked fixed because it seemed like all we needed was the UI for
the new timeout-based pref.  Looking back on it, I don't think we should hook
this up to the UI at all.  I don't like the false-positive debugger users will
run into when stepping over a window.open call.  Bug 132031 should probably be
closed WONTFIX.

A timeout-based solution was chosen because it was easy to implement.  The first
patch took me all of about 30 minutes to hack together.  It's not my job to stop
pop-ups.  I just saw what I thought would be an easy work-around, and did it.  
 I encourage any of you to Just Do It.  I'll be happy to review your work.

The main pref (the one that is actually hooked up to the UI) was introduced in
bug 92955.  The first patch there actually looked at the xpconnect stack to deny
anything that came from "onload" or "onunload".  One could use something similar
to *allow* only "onclick"s.  I'm not sure how you'd find out if you were in a
javascript: url, but it's probably possible.

If you were to try something like that, you'd probably do it in
CheckForAbusePoint, which is here:
<http://lxr.mozilla.org/mozilla/source/dom/src/base/nsGlobalWindow.cpp#2816>.

Comment 65

[Alfonso Martinez]

*** Bug 158705 has been marked as a duplicate of this bug. ***

Comment 66

[Rob McMillin]

Robert Ginda: re your comment 64, are you saying that a patch to prevent window 
openings shouldn't be attached to the "Open Unrequested Windows" checkbox?

Comment 67

[Robert Ginda]

There are two prefs here.  The first was introduced in bug 92955, and is
"dom.disable_open_during_load".  This pref blocks window.open() calls that are
made from script that runs outside of any function, from an onload or onunload
event, or from a setTimeout/setInterval.  This pref is what is currently hooked
up to "Open unrequested windows".  I think it's just dandy, and it does the job
fine for me.

Then the ny times came along and put a window.open in an <IMG> onload handler.
Maybe they did it to get around "dom.disable_open_during_load", or maybe it was
dumb luck.

As a quick hack, I came up with a SECOND pref, "dom.disable_open_click_delay",
which blocks window.open calls based on how soon they happen after a mouse
click.  This pref was never added to the UI, instead bug 132031 was filed with
the hopes that someone else would do it.  In comment 64, I suggested we
SHOULDN'T add this pref to the UI, because "dom.disable_open_click_delay"
probably isn't the right idea, and it is prone to false positives.

Instead, I say "dom.disable_open_click_delay" should probably be backed out.


Looking back at nsGlobalWindow.cpp now, I think we can once again scrap the idea
of looking at the xpconnect stack, and instead set a mInClickEvent flag in
GlobalWindowImpl::HandleDOMEvent.  This flag would only be true for the life of
the HandleDOMEvent call, when aEvent->messsage was NS_MOUSE_RIGHT_CLICK (and
whatever else makes sense.)  We would still need to work out javascript: urls,
unless they are dispatched from the NS_MOUSE_RIGHT_CLICK event (which would
things very easy.)

Comment 68

[Mike Young]

rginda, would you want to back out the patch here and create a new bug to
"Strengthen Disable Open Unrequested Windows"? marking this bug as dup?

I think your proposed idea seems about right, but I think we should be able to
determine the source of the call to the function without resorting to flags for
onClick. (although I might be wrong...)

From what I see, there are only the following _valid_ requested windows (I am
open to additions...):

1. Opened from the interface (in new window, middle click, File > New, Accel-N,
etc.) -- I believe that these are already immune and don't need to be worried about.
2. Opened via an onClick, onDblClick, onMouseDown, onMouseUp, onKeyPress,
onKeyDown, onKeyUp, onSubmit?(debatable).
3. Opened via a javascript: URL of a clicked link.

The onSubmit is not necessarily a user-activated event, but is often used as
such. (I would say onFocus too, but the idea of someone *requesting* a popup
window via tabbing into a field seems far-fetched.) The problem is that a
malicious web developer could call a submit() routine on a form with no visible
elements and no href and effectively get around the popup blocking. 

Comment 69

[Jason Bassford]

I agree that a new bug is needed at this point so as to avoid confusion. 
(Neither this bug nor bug 132031 really cover what we want, which is "Strengthen
Disable Open Unrequested Windows" as just suggested.)

Comment 70

[Robert Ginda]

> rginda, would you want to back out the patch here and create a new bug to
> "Strengthen Disable Open Unrequested Windows"? marking this bug as dup?

Maybe.  Maybe this bug should stay open so folks can find it, and "Strengthen
Disable Open Unrequested Windows" should be marked as blocking this bug.

> I think your proposed idea seems about right, but I think we should be able to
> determine the source of the call to the function without resorting to flags for
> onClick. (although I might be wrong...)

I'm not sure how you're going to know that window.open was called from an
onclick event without maintaining some sort of state to that effect.  Unless you
resort to the xpconnect stack checking code.

> 1. Opened from the interface (in new window, middle click, File > New, 
> Accel-N,
> etc.) -- I believe that these are already immune and don't need to be worried
> about.

Correct, windows opened from chrome code are always allowed, that's what the |if
(item)| condition in GlobalWindowImpl::CheckForAbusePoint is doing.

> 2. Opened via an onClick, onDblClick, onMouseDown, onMouseUp, onKeyPress,
> onKeyDown, onKeyUp, onSubmit?(debatable).
> 3. Opened via a javascript: URL of a clicked link.

what about |document.location = "javascript:void window.open('foo.html');";|?

I think this whitelist idea has more nooks and crannies than people suspect.  If
you open "Strengthen Disable Open Unrequested Windows", don't assign it to me
(cc: is ok.)  I'll help out where I can, but I don't have the kind of free time
I think it will take to get this right.

Comment 71

[Mike Young]

I have filed bug 159036 to deal with the issue of Strengthening Disable Open
unrequested windows.

I have added only rginda to the CC list (because i usually hate it when people
CC me without permisssion, so if you are on this list you have to add yourself)

I have answered rgindas comment about document.location = javascript: there

And if that bug is fixed, it will in turn fix this bug...

The issue still exists about backing out the patch in this bug.

Comment 72

[Matthias Versen [:Matti]]

*** Bug 159385 has been marked as a duplicate of this bug. ***

Comment 73

[Daniel Wang]

*** Bug 160527 has been marked as a duplicate of this bug. ***

Comment 74

[Daniel Wang]

*** Bug 153825 has been marked as a duplicate of this bug. ***

Comment 75

[Alfonso Martinez]

*** Bug 160652 has been marked as a duplicate of this bug. ***

Comment 76

[Jonas Jørgensen]

Filed bug 160670, "back out dom.disable_open_click_delay".

Comment 77

[Boris Zbarsky [:bzbarsky]]

*** Bug 161366 has been marked as a duplicate of this bug. ***

Comment 78

[Phil Schwartau]

*** Bug 157629 has been marked as a duplicate of this bug. ***

Comment 79

[Jonas Jørgensen]

Should we mark this dupe of bug 159036 (strengthen via whitelist)?

Comment 80

[Eric Vaandering (no email)]

I would advocate leaving it open for discoverability (searching on NY times).
Just look at the names or the URLs in the Dupes.

Comment 81

[Mike Young]

Hopefully bug 159036 will be the chosen solution to fix this bug, but it is
still a different bug. There is always the possibility that the developers would
like to fix this bug by simply blocking IFRAMES. Leave this bug open, but if you
have some free time to write code, try your hand at 159036 before you work
here... :-)

Comment 82

[Robert Ginda]

Another workaround (besides disabling iframes) is to completely turn off
window.open for nytimes.com.  Something like this...

user_pref("capability.policy.popupsites.sites", "www.nytimes.com");
user_pref("capability.policy.popupsites.Window.open", "noAccess");

Comment 83

[tom.williams]

>>Another workaround (besides disabling iframes) is to completely turn off
>>window.open for nytimes.com.  Something like this...

>>user_pref("capability.policy.popupsites.sites", "www.nytimes.com");
>>user_pref("capability.policy.popupsites.Window.open", "noAccess");

Would the user then have to configure EACH and every address to block?  I
reported this same problem but on a DIFFERENT website and that bug was marked as
a dupe of this one.

Peace.....

Comment 84

[Robert Ginda]

You can add more sites to the "popupsites" zone by listing them in the .sites
pref, like...

user_pref("capability.policy.popupsites.sites", "www.nytimes.com
www.someothersite.com www.yasite.com");

Comment 85

[Kai Lahmann (is there, where MNG is)]

*** Bug 163037 has been marked as a duplicate of this bug. ***

Comment 86

[tom.williams]

>>You can add more sites to the "popupsites" zone by listing them in the .sites
>>pref, like...

>>user_pref("capability.policy.popupsites.sites", "www.nytimes.com
>>www.someothersite.com www.yasite.com");

Ok, will there be an interface element to this ".sites" pref file through the
browser or is this something the end user will have to modify manually?

I think a browser interface element would minimize bug reports as people
"discover" (after filing the bug report) that they must edit the  ".sites" file.

Peace.....

Comment 87

[Jerry Baker]

Add Yahoo to the mix. I just visited http://news.yahoo.com/ with 2002082109
trunk and up came the plague of the Internet (an X2 spycam popup).

Comment 88

[Rob McMillin]

Will all due respects to Jerry Baker's comment 87, the X cam is not the 
*plague* of the internet, but the plaque of the internet, i.e., what you get 
for not brushing and flossing your web browser's source code.  Vote for bug 
126224 today!

Comment 89

[Daniel Wang]

sorry if I am wrong, I can't find any code in nsGlobalWindow.cpp
CheckForAbusePoint() that blocks onunload pop-ups.

Comment 90

[Daniel Wang]

sorry if I am wrong, I can't find any code in nsGlobalWindow.cpp
CheckForAbusePoint() that blocks onunload pop-ups.

Comment 91

[Vladimir Ermakov]

*** Bug 161975 has been marked as a duplicate of this bug. ***

Comment 92

[Robert Ginda]

Daniel, you are wrong.  Look at the code that sets mIsDocumentLoaded.

Comment 93

[Daniel Wang]

Robert, yes, thank you.

seamonkey/source/dom/src/base/nsGlobalWindow.h line 294
PRPackedBool mIsDocumentLoaded; // true between onload and onunload events

Comment 94

[Davor Cubranic]

The workaround described in comment 82 with setting capability.policy.popupsites
does not work for me (build Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0)
Gecko/20020529). I added the two lines to prefs.js, but the NYTimes popup still
appears. Has this been added in a later build than what I have installed?

Comment 95

[Sander]

In response to comment 94: since 0.9.9 you also need to add this line:
user_pref("capability.policy.policynames", "popupsites");
see: http://www.mozilla.org/projects/security/components/ConfigPolicy.html

An easier fix against all popups like these is of course setting this preference:
user_pref("dom.disable_open_click_delay", 1000);

*winces as he spams another load of people*

Comment 96

[André Dahlqvist]

*** Bug 178082 has been marked as a duplicate of this bug. ***

Comment 97

[Matthias Versen [:Matti]]

*** Bug 178644 has been marked as a duplicate of this bug. ***

Comment 98

[Jeremy M. Dolan]

*** Bug 179088 has been marked as a duplicate of this bug. ***

Comment 99

[Sébastien Delahaye]

*** Bug 181109 has been marked as a duplicate of this bug. ***

Comment 100

[Eric Lecht]

Don't know if this helps, but at least in w/ 1.2.1 the uninvited pop-ups happen
only going BACKWARD in the browser, from an article back to, say, the home page,
at least for me.

OTOH, the slick Tabs function (thankyouthankyouthankyou) has sort of relegated
the Back button to, er, the dustbin of history. Quiz: who said that??
BTW, I'm not a programmer, just a simple WAN analyst....one who really
appreciates Mozilla, I introduce all my (L)users to it....
NYTimes opening pop-ups is simply annoying, an in-your-face by heartless
adverti$ing wonks....and the ads! So cheesy...

Cheers!

Comment 101

[Matt Fago]

I swear this didn't happen in 1.3a, but it is certainly present in 1.3b. Any
luck with a fix?

What's up with the new "popup windows" preferences anyhow?

Comment 102

[Matthias Versen [:Matti]]

*** Bug 195653 has been marked as a duplicate of this bug. ***

Comment 103

[Daniel Wang]

*** Bug 195466 has been marked as a duplicate of this bug. ***

Comment 104

[Prachi Gauriar]

*** Bug 186850 has been marked as a duplicate of this bug. ***

Comment 105

[Gilles Durys]

*** Bug 200107 has been marked as a duplicate of this bug. ***

Comment 106

[Eric Lecht]

FYI, I am using 1.3 stable Mozilla, and every now and again NYT squeaks one by
the pop-up filter. Since I do tabbed browsing, and almost never hit the 'back'
button, this happens only when accessing www.nytimes.com front page. 
From there I think I have had like 1 pop-up *ever* accessing a page further in,
and I read nytimes several times daily.
I wonder-do they have some guy out there that does nothing but try and defeat
Mozilla's pop-up filter?

Weird.

Eric

Comment 107

[Michael W. Burden]

Mozilla's popup blocking also fails to block a popup on Consumer Reports'
webpage (http://www.consumerreports.org/main/home.jsp).   This popup window
appears to be initiated by mouse-over events on the navigation bar at the
top of the page.


These appear to be the relevant sections of code:


<script language="JavaScript">
<!--
function showWindow(e) {
    var x=y=0;
    if (e != '') {
        x = e.screenX;
        y = e.screenY;
    }

   
myWindow=window.open('http://cdn.consumerreports.org/static/popup/didyouknow.html','windowName',
        'width=200,height=300,screenX=' + x + ',screenY=' + y + ',left=' + x +
',top=' + y);
}
//-->
</script>



<tr><td><div align="center" class="blackbold_16-px"><a href="#" onClick="if
(window.event || document.layers) showWindow(window.event); else
showWindow('');"  onMouseOver="if (window.event || document.layers)
showWindow(window.event); else showWindow('');"><img
SRC="http://cdn.consumerreports.org/static/popup/didyouknow.gif" alt="Did you
know?" width="109" height="39" border="0"></a></div></td></tr>

Comment 108

[Chris Casciano]

*** Bug 202494 has been marked as a duplicate of this bug. ***

Comment 109

[Matthias Versen [:Matti]]

*** Bug 202745 has been marked as a duplicate of this bug. ***

Comment 110

[Jo Hermans]

*** Bug 204768 has been marked as a duplicate of this bug. ***

Comment 111

[Ed Hume]

Another site can evade Firebird's popup blocker.

From http://www.geocities.com/rosannaarquette2/ select
http://www.geocities.com/rosannaarquette2/pictures.html.
You will be presented with a series of popup windows from http://www.popupad.net.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030516 Mozilla
Firebird/0.6, popup blocking and javascript both enabled. When javascript is
disabled, the popup windows are not launched.

Comment 112

[Samuel Sieb]

It happens in mozilla as well.  It's a form submission, so it almost doesn't fit
in this bug.  Here's the code that does it:

<script language=JavaScript>
<!--//
 function loadpopup()
 {
    document.flauncher.submit();
    focus();
    setTimeout('focus()',2000);
  }
// -->
</script>
</head>
<body BGCOLOR="#E4ECF6" onLoad='loadpopup()'>
<form name='flauncher' action='http://www.popupad.net/ats/switch.php'
target='adv' method='post' onSubmit='focus();'>

Comment 113

[Erik]

Samuel (and possible Ed Hume): yours are different from this bug report since
this one is about opened popups created by img onload event - yours are created
using onload form.submit. This is currently discussed in bug #144726 so you may
also want to add yourself to the CC-list there.

Comment 114

[David G King]

Comment #112 confuses me a bit (so what's new). Is it the "onLoad" in the "body"
tag, or the "action" in the "form" tag that is causing this particular popup?

In any case, the original report in Bug #144726 has the same source as Comment
#112. In other words, don't post an answer to my question to this bug, just send
private eMail or post to Bug #144726.

Comment 115

[Mitchell Stoltz (not reading bugmail)]

Moving Popup Blocking bugs to XPApps, assigning to shliang

Comment 116

[Matthias Versen [:Matti]]

*** Bug 209386 has been marked as a duplicate of this bug. ***

Comment 117

[alanjstr]

I have yet to get an unrequested popup from NYTimes and I visit it daily
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030911
Firebird/0.6.1+

Comment 118

[Daniel Veditz [:dveditz]]

The NYTimes may have stopped annoying its customers but the technique described
in this bug still needs to be addressed.

Comment 119

[Alan Batie]

I agree with the comments that when user says "block unrequested popups" that's
what they mean, no matter how they're created.  I just ran across an annoying
popup ad (though interesting in that it's borderless) on the Channel 4 (british
tv) website:
http://www.channel4.com/entertainment/tv/microsites/G/graham/weblogs/index.html

This appears to be the offending section, but I've never heard of an iframe tag
before:

<script language="JavaScript"><!--
					if (!document.c4Category) document.c4Category = "";
					if (!document.c4Module) document.c4Module = "";
					banStr =
"category="+document.c4Category+"&module="+document.c4Module+"&content="+document.c4Content+"&size=468_60&";
					var now = new Date(); RND = now.getSeconds();
					document.write ('<iframe width="468" height="60" marginwidth="0"
marginheight="0" hspace="0" vspace="0" frameborder="0" scrolling="no"
bordercolor="000000" src="http://ads.channel4.com/html.ng/site=C4&'+ banStr
+'Rnd='+ RND + '">');
					document.write ('<scr'+'ipt language="JavaScr'+'ipt"
src="http://ads.channel4.com/js.ng/params.richmedia=yes&site=C4&'+banStr+'Rnd='+
RND + '"></scr'+'ipt>');
					document.write ('</iframe>');//--></script>

Comment 120

[Aaron Sherman]

iframe was, I think, created by Microsoft but is now supported by most browsers.
What I've never heard of is scrolling=no, which is what would appear to make it
"popup-like" in that it's positioned during redering, and then never moved as a
result of scrolling. Personal opinion here: "scrolling=no" should not be obeyed
if  popups are disabled. There's just no good reason for it....

Comment 121

[Jesse Ruderman]

The testcase WFM (I don't get any pop-ups) in
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040131
Firebird/0.8.0+ (aebrahim)

(That build is before danm's checkin for bug 197919.)

Comment 122

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

All testcases WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a)
Gecko/20040209.

Michaell confirmed WFM on IRC.