232115 - popup blocker should be more clever

Status: RESOLVED DUPLICATE of bug 165523

(SeaMonkey :: General, defect)

Description

[Alexandre Gomes]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040120
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040120

I used Avant browser for a long time before Mozilla. I really think you should
take a look at its tabs beaviour and the popup/image/etc... blockers.

When we click a link we expect to open something, right? this works fine with 
popup blocker disabled or when the link don't opens a popup. The thing is:

* Popup blocker should block any javascript window.open when not fired from a
event ("onclick", "onmousedown",...)
* maybe the exception in when the link have a href!="#" or href!="" because this
cases ensure that the developper objective is to fire a popup in the actual
context of application

Note: do not forget that the "#" because many developpers use it so the mouse
cursor changes when over the link



Reproducible: Always

Steps to Reproduce:
1. enable popup blocker
2. click a link that should open a popup

Actual Results:  
popup blocker blocks the WANTED popup

Expected Results:  
do not block it

Also note that using midle button always opens it.

Comment 1

[Joe Infla]

Reporter, would you please provide an example (or a few) of wanted popups that
don't fire when clicked on?

Comment 2

[Dan M]

I'm having some trouble following you. For example when you say "Popup blocker
should block any javascript window.open when not fired from a event" ... I've
read that four times now, and I can only conclude you mean just the opposite.

Considerable analysis has already been done on the issue of which windows to
block. Bug 159036 and bug 197919 are the current forerunners. Unless I just
misunderstand, this bug is a duplicate of one of those. Alexandre, if you have
in mind something not already covered by one of those bugs perhaps it would be
best to add a comment there.

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

Comment 3

[Dan M]

I'm beginning to get it. I'm with Joe. Please provide examples. The current
blocker is very simple-minded. The set of improperly blocked windows is very
minimal. (It will grow with bug 197919!) It's almost certain you're talking
about bug 101190 or the (somewhat) well-known issue that some websites, for some
reason, use timers to open windows in response to a user click, instead of
opening the window directly. I believe there's no open bug on that second issue.
Wouldn't hurt to open one, I suppose. I don't see it being fixed.

Comment 4

[Wenqing Jiang]

Hello, I'm trying to open a bug but find this one, which should
address the problem I'm gonna report.  I'm giving two examples
(popup blocking enabled), in one case after a click another
window is opened (which is desired); in another case it is not
(which is not desired - we hope the new window would be opened
up):

example #1:
1. go to http://www.lemonde.fr/
2. scroll down a little bit, and find a small picture with
   "dessins du jour" text just on top of it
3. click on the picture and a new window openes

example #2:
1. go to http://www.city.toronto.on.ca/torontomaps/
2. click on "go directly to Toronto maps"
3. in the "No. and Street Name" field, type in:
     65 Grand Marshall Drive
   and then click on "GO" button
4. a map will show up, and in the row of buttons just
   above the map, click on the print icon.
5. a small form appears below the map.  Click on
   the submit button, and nothing will happen.
   - this is not desired.  If you try it on IE (or
   disable the popup blocking in mozilla), a new
   window will popup with the map, and you can
   select File->Print in that window.

So, I'm wondering why I saw different behaviours
when having popup blocked in both cases.  I'm not
a tech guy on this kind of issues but I believe
the window in the second case shouldn't be blocked.

Comment 5

[Dan M]

Ah, the serendipity of new bugs. Well, in comment 4, the Le Monde example isn't
a popup window at all. One could perhaps expect that the popup blocker should
prevent any new window from opening, ever, but that's really not what it was
designed to do.

The second example is very complex HTML which I haven't traced all the way
through. But I'll still say that what's happening is this: in response to a form
submission, the client (Mozilla) begins a page load. It's expecting to display
the server's response. This server resends the same page to preserve the map
data, but with some extra script that, while the page is (re)loading, opens a
separate window with a printer-friendly version of the map. That's very nice,
and it'll run afoul of the popup blocker which will certainly block a web page
from opening a new window while it's loading. That *is* what it was designed to do.

Should the blocker make an exception for a document that's being loaded in
response to a user action like form submit, and wants to open a new window?
That's debatable. I say no. It's not very different from clicking a link to go
to some other website, and getting a popup window from there. This is the kind
of thing the blocker's whitelist is for. Sometimes you really do want the window
and the blocker just can't tell it's desirable content.

I know which bug this is a duplicate of. It's chofmann's metabug for popup
blocker issues. I've moved example #2 to that bug, and I'm closing this one.

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