Better Popup Window Blocking has arrived
Mitchell Stoltz
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
> 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
> 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
> 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
>> 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
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
> 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
> 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
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
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
> 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
> 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