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

VERIFIED WORKSFORME

Status

VERIFIED WORKSFORME
17 years ago
5 years ago

People

(Reporter: mozilla.org, Assigned: shliang)

Tracking

({relnote, testcase})

Trunk
Future
relnote, testcase

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

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

17 years ago
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 -
Assignee: rogerl → sgehani
Component: JavaScript Engine → Preferences
QA Contact: pschwartau → sairuh
I see this on linux too
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All

Comment 3

17 years ago
CC'ing Doron.
Keywords: helpwanted
Target Milestone: --- → Future
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.
Assignee: sgehani → mstoltz
QA Contact: sairuh → bsharma

Comment 5

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

Comment 6

17 years ago
I captured the script at:

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

Comment 7

17 years ago
Created attachment 71223 [details] [diff] [review]
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

17 years ago
Created attachment 71224 [details]
testcase

Comment 9

17 years ago
Created attachment 71225 [details] [diff] [review]
patch without printf and commented out code
Attachment #71223 - Attachment is obsolete: true

Comment 10

17 years ago
Mitch, would you like to drive this one into the tree again?
Keywords: helpwanted → mozilla1.0, patch

Comment 11

17 years ago
jst, got time for a sr?
*** Bug 127573 has been marked as a duplicate of this bug. ***

Comment 13

17 years ago
*** Bug 123647 has been marked as a duplicate of this bug. ***
*** Bug 128974 has been marked as a duplicate of this bug. ***
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
Attachment #71225 - Flags: superreview+
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.
Attachment #71225 - Flags: review+

Comment 17

17 years ago
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
Attachment #71225 - Flags: approval+

Comment 18

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

17 years ago
Created attachment 73206 [details] [diff] [review]
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.)
Attachment #71225 - Attachment is obsolete: true

Comment 20

17 years ago
jst, if you'll give the latest patch your blessing, I'll check it in when the
tree opens.
Comment on attachment 73206 [details] [diff] [review]
updated patch

sr=jst
Attachment #73206 - Flags: superreview+
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?
Attachment #73206 - Flags: review+
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

17 years ago
Checked in to trunk.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 25

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

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

17 years ago
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>
Keywords: relnote

Comment 28

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

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

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

Comment 31

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

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

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

Comment 34

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

Comment 35

17 years ago
*** Bug 139318 has been marked as a duplicate of this bug. ***
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

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

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

Comment 39

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

Comment 40

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

Comment 41

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

Comment 42

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

Comment 43

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

Updated

17 years ago
Summary: NY Times web sites creates pop-up windows even if that feature is disabled → NY Times web sites creates pop-up windows even if that feature is disabled (using img onload)

Comment 44

17 years ago
*** Bug 154270 has been marked as a duplicate of this bug. ***
*** Bug 154476 has been marked as a duplicate of this bug. ***

Comment 46

17 years ago
*** Bug 155134 has been marked as a duplicate of this bug. ***
*** Bug 155545 has been marked as a duplicate of this bug. ***
*** Bug 155901 has been marked as a duplicate of this bug. ***

Comment 49

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

Comment 50

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

Comment 51

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

Comment 52

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

Comment 53

17 years ago
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?

Updated

17 years ago
Alias: nytimes

Comment 54

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

Comment 55

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

Comment 56

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

Comment 57

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

Comment 58

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

Comment 59

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

17 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 61

17 years ago
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.

Updated

17 years ago
Keywords: mozilla1.0 → mozilla1.1

Comment 62

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

Comment 63

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

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

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

Comment 66

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

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

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

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

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

17 years ago
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.
Depends on: 159036
*** Bug 159385 has been marked as a duplicate of this bug. ***

Comment 73

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

Comment 74

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

Comment 75

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

Comment 76

16 years ago
Filed bug 160670, "back out dom.disable_open_click_delay".
*** Bug 161366 has been marked as a duplicate of this bug. ***

Comment 78

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

Comment 79

16 years ago
Should we mark this dupe of bug 159036 (strengthen via whitelist)?
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

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

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

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

16 years ago
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");
*** Bug 163037 has been marked as a duplicate of this bug. ***

Comment 86

16 years ago
>>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.....

Updated

16 years ago
Blocks: 163993

Comment 87

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

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

16 years ago
sorry if I am wrong, I can't find any code in nsGlobalWindow.cpp
CheckForAbusePoint() that blocks onunload pop-ups.
Summary: NY Times web sites creates pop-up windows even if that feature is disabled (using img onload) → (NY Times) Web sites can create pop-up windows using img onload even if unrequested window is blocked

Comment 90

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

Comment 91

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

Comment 92

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

Comment 93

16 years ago
Robert, yes, thank you.

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

Updated

16 years ago
Blocks: 176958

Comment 94

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

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

16 years ago
*** Bug 178082 has been marked as a duplicate of this bug. ***
*** Bug 178644 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Summary: (NY Times) Web sites can create pop-up windows using img onload even if unrequested window is blocked → (NY Times) Web sites can create pop-up windows using img onload even if unrequested window is blocked (nytimes, image, popup)

Comment 98

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

Comment 99

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

Comment 100

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

16 years ago
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?
*** Bug 195653 has been marked as a duplicate of this bug. ***

Comment 103

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

Comment 104

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

Updated

16 years ago
Keywords: mozilla1.1

Comment 105

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

Comment 106

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

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

16 years ago
*** Bug 202494 has been marked as a duplicate of this bug. ***
*** Bug 202745 has been marked as a duplicate of this bug. ***

Comment 110

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

Comment 111

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

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

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

16 years ago
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.
Moving Popup Blocking bugs to XPApps, assigning to shliang
Assignee: mstoltz → shliang
Status: REOPENED → NEW
Component: Preferences → XP Apps
*** Bug 209386 has been marked as a duplicate of this bug. ***

Comment 117

15 years ago
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+
The NYTimes may have stopped annoying its customers but the technique described
in this bug still needs to be addressed.

Comment 119

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

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

15 years ago
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.)
All testcases WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a)
Gecko/20040209.

Michaell confirmed WFM on IRC.
Status: NEW → RESOLVED
Last Resolved: 17 years ago15 years ago
Resolution: --- → WORKSFORME

Updated

14 years ago
Blocks: 253831

Updated

14 years ago
No longer blocks: 176958
Product: Core → Mozilla Application Suite

Updated

14 years ago
No longer blocks: 163993

Updated

9 years ago
Status: RESOLVED → VERIFIED
Keywords: testcase
Alias: nytimes
You need to log in before you can comment on or make changes to this bug.