Closed Bug 150340 Opened 23 years ago Closed 12 years ago

plugins don't obey the "Open unrequested windows" pref

Categories

(Core Graveyard :: Plug-ins, defect, P5)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: buddlight, Assigned: peterl-bugs)

References

(
URL
)

Details

(Whiteboard: [PL2:P5]) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
BuildID:    2002053012

I disallow javascripts to "Open unrequested windows".  I've encountered many
sites that use Macromedia Flash applets+javascripts to open new windows.  Most
of these sites do work, but some don't.  The 6th Day web site is one of them. 
There's are these buttons: SUBMIT, SWEEPSTAKES, SCREENSAVER, VIEW THE TRAILER. 
All of those buttons work except VIEW THE TRAILER.  :(

Reproducible: Always
Steps to Reproduce:
1. Disallow javascripts to "open unrequested windows"
2. Visit http://www.sonypictures.com/movies/the6thday/
3. Click "Enter," then click "skip intro."
4. Click "VIEW THE TRAILER".  Doesn't work.

Actual Results:  No popup

Expected Results:  a popup

It works when I allow javascripts to open unrequested windows.
At a guess, the flash code opens the window on a timeout, so it looks exactly
like a popup.

The non-flash version of this page does not exhibit the problem, btw, so flash
is needed to reproduce.
not sure if we can do anything about it short of prohibiting all flash movies to
open new windows

-> plugins
Assignee: Matti → beppe
Component: Browser-General → Plug-ins
QA Contact: imajes-qa → shrir
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
Build: 2002053012

Confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yahoo's "View Slideshow" does not work either, and has nothing to do with Flash,
is this the same problem, or something else?
http://news.yahoo.com/
Yahoo's view slideshow works fine for my build on Win2k!
where's the setting under prefs?  
-->FUTURE

This would be hard to fix correctly and it's very low priority.

This pref is nothing but trouble, don't use it!
Assignee: beppe → peterl
Priority: -- → P5
Summary: Requested Windows Not Popping Up → plugins don't obey the "Open unrequested windows" pref
Target Milestone: --- → Future
This might be a dup of bug 122927.
Severity: minor → normal
*** Bug 122927 has been marked as a duplicate of this bug. ***
Whiteboard: [PL2:P5]
> This pref is nothing but trouble, don't use it!

This pref is the single thing that got me to switch from NN4 to Mozilla. The
same can be said for dozens of users that learned of this pref in the
macromedia.dreamweaver group. Please don't let the main reason for using Mozilla
wither on the vine.
Blocks: 158464
What is a way for plugin to open new window? Is it a part of Mozilla common
plugin interface or a feature of internal plugin code?

If first, then fixing of this bug, IMHO, might be not so hard work.

It can be internal plugin code.
Because plugins are running as native code, there are many ways it can open a
window. Here are just a few examples I could think of right now:

1. Using NPN_GetURL/PostURL/Notify, the API allows for specifying a target
frame. This can be _blank or a named frame. The default plugin uses this.
2. Using the same functions, a javascript: URL can have a window.open.
3. Using a combination of the methods above, a document.write could be injected
to an already open window
4. Plugins could even load a local file into an already open window that uses
one of the methods above
5. Plugins can always show a native dialog such as the Java console. We can't
stop that.
6. Using NPN_NewStream, a plugin could write out a new document that may have
open a new window right away or have JS do it later.
7. Since plugins have access to the service/component manager, it would even be
possible for plugins to detect this pref is on, turn it off, then show its'
popup window in any way it likes.

On top of all that, fixing this bug may cause many plugins and sites to break or
not work as expected. This is already the case with using this pref with
Netscape Radio. That's why I say don't use it.
I doubt it's even possible to detect if a window opened by a plug-in
is "unrequested". bug 103843 is a possible solution though.

setting 103843 dependency

related: bug 146873
Depends on: 103843
Blocks: popups
The solution is easy: fix it so that OnClick and a few other events are allowed 
to open up windows.  In other words, "requested windows".  This simple problem 
has continued to be a problem for the past several months, and it requires less 
than 10 lines of code to fix.

Fix it.  Thank you.
You obviously have no idea what you're talking about... if a plugin wants to
open a window, we have no way at all of stopping it.  On windows, it can just
send a DDE request which is identical to you clicking a link in word or
double-clicking a desktop icon, or whatever.
Then perhaps bug 122927 is not a duplicate of this bug.  If that is the case, 
then unmark it as such.

I simply want to click on a link that opens up a "popup" window, and not have 
it blocked by the "Open unrequested windows" switch.  Since I requested it, I 
want it opened.  Unrequested would be something like Load or Unload or pretty 
much anything on a BODY tag.  I think I have the snipet of code that controls 
this here (in nsGlobalWindow.cpp):

2752 static
2753 PRBool IsPopupBlocked(nsIDOMDocument* aDoc)
2754 {
2755   PRBool blocked = PR_FALSE;
2756   nsCOMPtr<nsIDocument> doc(do_QueryInterface(aDoc));
2757   nsCOMPtr<nsIPopupWindowManager> pm(do_GetService
(NS_POPUPWINDOWMANAGER_CONTRACTID));
2758   if (pm && doc) {
2759     nsCOMPtr<nsIURI> uri;
2760     doc->GetDocumentURL(getter_AddRefs(uri));
2761 
2762     PRUint32 permission = nsIPopupWindowManager::ALLOW_POPUP;
2763     pm->TestPermission(uri, &permission);
2764     blocked = (permission == nsIPopupWindowManager::DENY_POPUP);
2765   }
2766   return blocked;
2767 }

A few If statements would do the trick to see if the event that loaded it was a 
OnClick or an OnLoad/OnUnload/etc.  I'm not a Mozilla programmer, much less a 
C++ programmer, to be able to code the lines for this, but I'm really trying 
the best I can to help out in getting this one bug fixed.
Did you read bug 122927 comment 10?  The window is being opened asynchronously
from the onload event of an iframe that the plugin creates.  The only event
involved is "OnLoad".  That's a problem with that particular plugin's method of
opening windows.

Fwiw, I'm not sure that this is the right bug to dup to, but the module owner
(who actually _knows_ something about the plugin code, unlike you and unlike me)
thinks they are the same issue, so changes are that the same code-level changes
would be necessary to deal with both.
If that's the case, then where's the issue involving my bug?

After reading bug 176958 (for tracking issues relating to popup blocking), I 
don't think I can find a bug that's exactly my issue?

For an exact example:

1. Go to http://www.resonatorsoft.org/software/htmlspeak/demo/
2. Click on the About link on the bottom.

(The window doesn't show up when it should, based on a OnClick event.)

If there is no bug for this, please say so, and I'll create one.  (But, I'd be 
surprised, because I'd figure this would be a widely annoying bug.)
I did those steps.  I have unrequested popups disabled under Preferences >
Advanced > Scripts and Plugins.  The window came up fine.

Since that's not a plugins issue either way, please don't comment in plugins
bugs about it.
I *think* that Brendan might have been suggesting that the way Mozilla goes
about blocking popups is backwards. Instead of checking if a window is
*unrequested*, and trying to deal with all such cases (onload, onmouseover,
etc.), wouldn't it make more sense to block *ALL* popups unless they are the
result of a click?
Perhaps, if the concept was trackable in a useful way.  It is currently not.
Sorry, I posted that on a IE browser without the capability to check that.  Now
on Mozilla, I see that you're correct: it does work.  Hmmm...a few of the pages
I was having problems with works now.  This was fixed recently, but I can't find
the bug associated with it.

In any case, I apologize for bitching so much about it.  I'll post a new bug
report if I still find a case of it.
*** Bug 174370 has been marked as a duplicate of this bug. ***
Camino is a fine, /fine/, browser ... but this accesskey problem is the only
reason I'll venture back to Safari now and then.  (There's one website I
frequent for which the accesskeys are muscle memory now.)
(In reply to comment #25)
> Camino is a fine, /fine/, browser ... but this accesskey problem is the only
> reason I'll venture back to Safari now and then.  (There's one website I
> frequent for which the accesskeys are muscle memory now.)

My apologies ... wrong window, wrong bug!  (I'll just slink over here and hide
under some unwashed laundry and newspapers to be recycled.)
Blocks: pop-up-arms-race
No longer blocks: popups
Now it should work to block popups for plugins due to bug 258487, see bug 258487
comment 4 for details. Please test it with new builds.
Actually, no.  The pref added in that bug defaults to allowing plugins to open
popups.
(In reply to comment #28)
> The pref added in that bug defaults to allowing plugins to open popups.
Of course this hidden pref has to be set to 2 for example.


Yes, but this bug is about the fact that the general popup blocker UI doesn't
block popups from plugins.  Existence of that hidden pref does not change this
basic fact.
This bug appears to encompass both bug 176079 and bug 189237, looks like some
dupage is in order.
Original link is gone, add testcase from Bug 258487 with Java plugin.
URL: http://www.spe.sony.com/movies/the6th... → https://bugzilla.mozilla.org/attachme...
QA Contact: shrir → plugins
Blocks: 251793
can anyone either confirm this as fixed or should it stay open (using the latest
beast build)?
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.