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.