Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Better Popup Window Blocking has arrived

9 views
Skip to first unread message

Mitchell Stoltz

unread,
Aug 31, 2001, 4:10:11 PM8/31/01
to
I have just checked in a little hack that disables the window.open call
during onLoad and onUnload events, top-level scripts, and timeouts. This
should block 99% of pop-up or pop-under ads out there on the Web while
still allowing a page to open a window in response to a mouse click.
It'll be in today's trunk builds and on the 0.9.4 branch. To turn on
this feature, add this line to your prefs.js file (be sure to exit
Mozilla before editing prefs.js or your changes will be overwritten):

user_pref("dom.disable_open_during_load", true);

Please bear in mind that this is experimental, and it has some flaws: If
you hit the Stop button while a page is loading, then no calls to
window.open on that page will work. If this happens, just reload the
page. Please give this a try, and post feedback about how this feature
could be improved.

Thanks to Rob Ginda for contributing the original patch.

-Mitch

Ben Bucksch

unread,
Aug 31, 2001, 7:59:02 PM8/31/01
to mozilla-...@mozilla.org
Mitchell Stoltz wrote:

> Please bear in mind that this is experimental, and it has some flaws:
> If you hit the Stop button while a page is loading, then no calls to
> window.open on that page will work.

Any plans to fix that?

> Please give this a try

OK, will do.

> and post feedback about how this feature could be improved.

An UI (pref checkbox) would be an improvement :-). (But I guess, it
should first be non-experimental.)

> Thanks to Rob Ginda for contributing the original patch.

Many thanks to both of you!


Mitchell Stoltz

unread,
Aug 31, 2001, 11:27:15 PM8/31/01
to
Ben Bucksch wrote:

> Mitchell Stoltz wrote:
>
>> Please bear in mind that this is experimental, and it has some flaws:
>> If you hit the Stop button while a page is loading, then no calls to
>> window.open on that page will work.
>
>
> Any plans to fix that?

Yes. I'm also going to generalize it to other DOM calls.

> An UI (pref checkbox) would be an improvement :-). (But I guess, it
> should first be non-experimental.)


That's on my list too.

-Mitch


Jason Bassford

unread,
Sep 1, 2001, 8:59:53 AM9/1/01
to
> page. Please give this a try, and post feedback about how this feature
> could be improved.

Excellent! It works just fine so far, bypassing the need to have a
whitelist. I haven't yet seen a popup that I didn't want, nor have I
not receieved a popup that I did want.

It's interesting because just yesterday I was working with the
Bugzilla Helper and thought that something was wrong when none of the
submit buttons worked. It took me a while to figure out (and from
reading bug reports) that it was actually being caused by the old
style prevention of popups. But it wasn't obvious at first that this
was the problem.

I know you said that this patch may *sometimes* <1% give an
unwanted popup. Is there any chance that it could also sometimes
prevent a popup that you do want?

In all of these security type fixes (popups and cookies) I can see
how it might sometimes be useful to get some kind of status or
indication that somethings being prevented so that you can troublshoot
cases like this. However, doing so in a non-intrusive manner is
something else. (It would have to be a tray icon or something
similiar that flashes briefly when the blocking is in effect, that
would also let you click on it to get a log of recent activity.)

Anyway, a UI aside, which everybody knows about, the only other
addition would be something like the above - some way of knowing
what's going on should it be needed.

Jason.

Gervase Markham

unread,
Sep 1, 2001, 3:13:02 PM9/1/01
to
>> An UI (pref checkbox) would be an improvement :-). (But I guess, it
>> should first be non-experimental.)
>
> That's on my list too.

There's a bug on an entire prefs panel for this stuff. It would probably
be better just to put the pref name in the bug, and wait a bit :-)

Gerv

Mitchell Stoltz

unread,
Sep 4, 2001, 10:14:44 PM9/4/01
to

Jason Bassford wrote:


> I know you said that this patch may *sometimes* <1% give an
> unwanted popup. Is there any chance that it could also sometimes
> prevent a popup that you do want?


Of course. This isn't perfect. Like I said, if you hit Stop during a
load, the blocker bit may not be cleared, and no calls to window.open,
wanted or unwanted, will work on that page until it is reloaded.

Besides, maybe there's something that gets popped up on load or unload
that you do want to see. I doubt it. I'll build in the ability to create
an exception list for those cases should one arise.


>
> In all of these security type fixes (popups and cookies) I can see
> how it might sometimes be useful to get some kind of status or
> indication that somethings being prevented so that you can troublshoot
> cases like this. However, doing so in a non-intrusive manner is
> something else. (It would have to be a tray icon or something
> similiar that flashes briefly when the blocking is in effect, that
> would also let you click on it to get a log of recent activity.)


That's a good idea - a tray icon. Best solution to that problem I've
heard yet. The "log of recent activity" could be the JS console, which
actually gives some status messages which don't pertain to JS. Let's do
something like this - it could also handle the security error messages
from CheckLoadURI and others for which people have complained that they
can't tell when something's been blocked.
-Mitch

Giuseppe Verde

unread,
Sep 4, 2001, 5:39:50 PM9/4/01
to
Mitchell Stoltz wrote:

> I have just checked in a little hack that disables the window.open call
> during onLoad and onUnload events, top-level scripts, and timeouts. This
> should block 99% of pop-up or pop-under ads out there on the Web while
> still allowing a page to open a window in response to a mouse click.
> It'll be in today's trunk builds and on the 0.9.4 branch. To turn on
> this feature, add this line to your prefs.js file (be sure to exit
> Mozilla before editing prefs.js or your changes will be overwritten):
> user_pref("dom.disable_open_during_load", true);

Cool. That's a great addition.

Also, are there any plans to add something along the lines of "NoAction"
(pretend that the function call worked so that the script thinks all
is OK and doesn't get aborted, as happens with NoAccess)?

Ben Bucksch

unread,
Sep 5, 2001, 2:31:35 PM9/5/01
to mozilla-...@mozilla.org
Mitchell Stoltz wrote:

> Besides, maybe there's something that gets popped up on load or unload
> that you do want to see. I doubt it. I'll build in the ability to
> create an exception list for those cases should one arise.

FWIW, IIRC, there are some poorly written sites which desperately want a
certain window size (all-Flash sites usually) and then open a new window
with the wanted size onLoad on the homepage. Luckily, they are very rare.

> That's a good idea - a tray icon.

me too.


Mitchell Stoltz

unread,
Sep 5, 2001, 5:13:21 PM9/5/01
to

Giuseppe Verde wrote:


> Also, are there any plans to add something along the lines of "NoAction"
> (pretend that the function call worked so that the script thinks all
> is OK and doesn't get aborted, as happens with NoAccess)?
>

Yes, I plan to add that. Although if we make window.open be a no-op, the script is

likely to fail later when the object it's holding turns out not to be a valid

window.

-Mitch


Giuseppe Verde

unread,
Sep 5, 2001, 5:25:55 PM9/5/01
to
Mitchell Stoltz wrote:


Hrm. Good point. Maybe make a Window object, but don't allow it to
actually be shown? I'm not knowledgeable in JavaScriptiness, let
alone the implementation thereof, so I'm probably just talking
nonsense.... All I know is that some sites (e.g. www.weather.com
fail utterly when the window.open call fails (it never gets to the
redirect to the local zone. Try it by typing in your zip code on the
main page).

*sigh* So much to learn, so much to hack, so much homework to
procrastinate on. ;)

--Giuseppe
implementation thereof.

mi...@invalid.email.com

unread,
Sep 21, 2001, 1:54:39 PM9/21/01
to
Mitchell Stoltz <mst...@netscape.com> wrote:
> you hit the Stop button while a page is loading, then no calls to
> window.open on that page will work. If this happens, just reload the
> page. Please give this a try, and post feedback about how this feature
> could be improved.

Can you also start a timer to clear this condition? Or maybe clear
it when the stop button is pressed?

-Mike

Mitchell Stoltz

unread,
Sep 24, 2001, 3:36:05 PM9/24/01
to
mi...@invalid.email.com wrote:


> Can you also start a timer to clear this condition? Or maybe clear
> it when the stop button is pressed?
>
> -Mike
>


Not currently, but those are good ideas, so I think I'll use them.
-Mitch


0 new messages