161176 - lie to sites about whether window.open succeeded

Status: RESOLVED DUPLICATE of bug 181035

(SeaMonkey :: General, enhancement)

Description

[dirtside]

Right now, if you have Preferences > Advanced > Scripts & Plugins' "Open
unrequested windows" deactivated, then the browser will ignore certain
JavaScript window.open commands.  The problem here is that some sites can detect
this behavior; namely, if you click on a link on the site, the page you visit
attempts to open a small window that communicates with the server, verifying
that you aren't blocking popups.

Instead, what Mozilla should do is execute "blocked" requests, but NOT RENDER
THEM.  In other words, the browser executes the window.open command, and renders
the "window" internally, and then closes it when it finishes, all without ever
showing it to the user.  So as far as the user knows, there was no window.open()
command, but the site they're visiting can't tell whether or not the user
actually had to look at and read their stupid popup.

Probably should make it optional, since some people will not want Mozilla doing
this.  Another nice feature would be a dialog box that lists all "blocked"
connections Mozilla has made this session, or maybe a logfile that keeps track
of these on a per-user basis.

Comment 1

[Alfonso Martinez]

The last part of the bug is already requested. Search bugzilla.

For the rest of the bug: the point of disabling opening new windows is not only
to avoid new windows, but also to avoid unnecesary communication with any server
(user-tracking). If mozilla would "render internaly" those pages that point
would be lost.

I think that this bug should be WontFix

Comment 2

[alge]

If this is a valid bug at all, it's an enhancement.

Suggest changing summary to "RFE: make blocked popups render internally" or
something.

probably WONTFIX, though.

Comment 3

[Jesse Ruderman]

Wontfix: this would be a perf hit, a bandwidth hit, dishonest, impossible, etc.

If you don't normally use tabs, consider voting for bug 103843, which would let 
you make pop-ups open in tabs, which you could then close all at once along 
with the window.

Comment 4

[Matthias Versen [:Matti]]

v

Comment 5

[dirtside]

Did search Bugzilla, three separate terms, didn't come across another bug with
the same intent.

That's why I suggested this be *optional* (ideally, disabled by default, don't
put it in the config UI if you think it should be an uber-user kind of setting).
 If someone doesn't mind the popups' background actions, and wants to be able to
use this kind of site without having to manually turn "Open unrequested windows"
back on every time we visit that site, then it seems like a good idea at least.
 If you don't, then you don't, and you leave the option off (basically it's a
three-way option: Allow unrequested windows to open (either in a new window or
in a tab); render unrequested windows in the background and don't display them
(automatically stop rendering X seconds after the background window finishes
rendering, or timeout and close after Y seconds, whichever comes first); or
don't execute the unrequested open at all.

I *do* normally use tabs, but I don't usually have separate main windows with
separate topics open.  I just have everything in one window, but I use tabs
because I don't like my WM toolbar being cluttered up.

Perf hit, yes.  Bandwidth hit, yes.  But let the *user* decide if it's worth it
so that they can access sites that detect Mozilla not opening certain popup
windows.  If it's not worth it to a user, they don't use it.  And dishonest? 
How is disabling "Open unrequested windows" any different?  It's designed to get
around the *exact* same thing -- annoying popup ads.  Sites have come up with
ways to get around Mozilla disabling "Open unrequested windows" (try
eq.castersrealm.com or www.latimes.com -- I still get popups on those sites,
even with "Open unrequested windows" turned off), and Mozilla should respond to
those methods.

Comment 6

[Matthias Versen [:Matti]]

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

Comment 7

[slice1900]

I think this should be reconsidered -- I feel part of the reason it was given
WONTFIX is because the summary said it should "lie".  See the dup I filed, bug
#161209 for a more politically correct summary and description.  More and more
sites will start using this anti adblocker technology, mark my words.  After a
while, it'll be as useless to browse with "open unrequested windows" checked as
it currently is to browse with Javascript disabled.

Unless I'm way off base here, the reason the pref to disallow opening
unrequested windows was created in the first place was because users are very
annoyed with popup ads.  If web designers make changes that don't let users
browse their sites without receiving these ads, us users either have to be
annoyed or find another way to remove our annoyance.  Doing the work of
window.open for the ads without displaying them would be one way of doing this.
 This isn't "lieing" to sites about window.open succeeding -- it is merely
automating the process of closing the popups instantly so the users don't have
to.  It is no different than if someone wrote a small AI application that would
watch the browser and instantly detect any unwanted ads and close their windows
the instant they were displayed.  Yes, it is a performance hit, but if users are
forced to leave popups on when a majority of sites won't let you browse them
without showing the ads, those resources are used anyway.  I pay for the
bandwidth I use, and the web sites I visit pay for theirs.  It should be our
decision whether to waste that bandwidth grabbing those ads or not, we just want
a browser that gives us access to the greatest amount of content with the least
amount of unwanted annoyance.

Please reopen, or give better reasons than "bandwidth hit, dishonest".  The tab
suggestion is a good one, but only for people who don't normally use tabs.  From
there, it is a small step for tab users to request such windows be rendered in
special "ad tabs" that won't affect the normal tab browsing experience.  And at
that point, they might as well not be displayed at all, and we are back to the
suggestion on the table.

Comment 8

[Jesse Ruderman]

Reopening to mark as a dup of bug 181035...

Comment 9

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 181035 ***