bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

New method of unsolicited popup advertisements bypasses blocker



UI Design
14 years ago
14 years ago


(Reporter: A, Assigned: jag (Peter Annema))


Firefox Tracking Flags

(Not tracked)





14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030 Firebird/0.7+ (Mike Tigas (Nova); MNG; Ox,G6)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030 Firebird/0.7+ (Mike Tigas (Nova); MNG; Ox,G6)

Websites under the Lycos network (Lycos, Angelfire, and Tripod) have a new
method of popup blocking that works by infesting ALL links on the page with a
Javascript that opens popups.

Mozilla is tricked into thinking that the user is requesting the popup to be
opened, but actually the user is trying to visit an external page. Since the
popup comes at the same time as the newly loading, non-Lycos page, the user will
often assume that the popup ad is coming from the new page.

Reproducible: Always

Steps to Reproduce:
1. Disable cookies-- the script uses cookies so that only one popup opens per day.
2. Click the first link and no popup will open.
3. Click the second link and a popup advertisement will open.
4. Click the third link and a popup advertisement will open.
(Note: Lycos' popup code is subject to change)
Actual Results:  
The second two links open unsolicited popup ads.

Expected Results:  
Mozilla should block unsolicited popup ads.

Discussion thread at http://forums.mozillazine.org/viewtopic.php?t=44398

Suggested fix, maybe:
- Disabling access to document.getElementsByTagName('A') when the page loads (is
there any legitimate use for it?)
- Not allowing tags to be modified when the page loads (again, any legitimate use?)

Suggested workarounds for endusers:
- Set a cookie for .angelfire.com named "ExitPage", with the value "viewed",
that doesn't expire
- Simply disable Javascript, or turn off all popup windows
- Disable access to document.getElementsByTagName on Lycos using CAPS
- Void functions named buildExitHandler on Lycos

Comment 1

14 years ago
I see this bug. My build ID is:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040104 Firebird/0.7+

Comment 2

14 years ago
Probably the same as bug 226962.
Assignee: general → jag
Component: Browser-General → XP Apps
QA Contact: general → pawyskoczka
Unfortunately, there is really no way to tell that this is abusive -- this
technique is used by far too many respectable sites (cnn, new york times,
weblogs, etc).

Comment 4

14 years ago
This is bug 227338 (it helps to search for closed bugs when you're looking for
duplicates :-)). As I said in that bug, this script is equivalent to simply
writing a web page with click handlers that open new windows. These aren't
really popups. And as Boris said, I think it's impossible to distinguish between
these pseudo-popups and genuine content.

If we hamstring script in the name of "popup" protection, people will simply
begin hardcoding these click handlers. Worse, we become incompatible with
legitimate websites. It's out of the question. And obviously, we can't hardcode
into the client the voiding of functions named buildExitHandler on Lycos sites.
Also, on the subject of guarding against document.getElementsByTagName('A'),
note that the site mentioned in bug 227338 uses document.links.

However, as the practice becomes more common, it gets more annoying. See bug
227338 comment 2. Also see bug 197919, which suggests Mozilla make click
handlers subject to popup protection. That too would solve this problem, for now.

*** This bug has been marked as a duplicate of 227338 ***
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.