Closed Bug 122927 Opened 23 years ago Closed 22 years ago

java can't open window in response to click (when opening unrequested windows is disabled)

Categories

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

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 150340
Milestone:
Future

People

(Reporter: sjmccarthy, Assigned: peterl-bugs)

References

(
URL
)

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8+) Gecko/20020126 BuildID: 2002012608 If the preference "Open unrequested windows" is not selected (found under Edit:Preferences:Advanced:Scripts & Windows), then new windows will not open even when a button within a java applet is clicked. Reproducible: Always Steps to Reproduce: 1.Go to http://www.pogo.com 2.Click on the link 'Chess' in order to play chess 3.You must log in here (sorry, I don't know any other sites produce this bug and don't require a login, but creating an account is free) 4.Click on any of the room names (EG: Big Blue Sky). A new window will open up and a Java applet will load (you must have Java installed for this bug to work) 5.Make sure that the preference "Open unrequested windows" (found under Edit:Preferences:Advanced:Scripts & Windows) is NOT selected. 6.Find an empty table and click the "Play" button. An options window will pop-up hit PLAY. Actual Results: A new window containing the chess applet does NOT open. Expected Results: A new window containing the chess applet should open. If the "Open unrequested windows" option is selected then the chess applet does open. Since this window IS requested it should open. This problem occurs on both my windows and Linux computers.
To OJI
Assignee: idk → joe.chou
Component: Java-Implemented Plugins → OJI
QA Contact: avm → pmac
Huh, I think that this window IS NOT requested :-) Not a bug IMHO. (As far as I understand, unrequested window is any window not opened by File->New.... or by its shortcuts).
In response to #2: I'm pretty sure that this is a bug. When you are browsing regular websites (non-java), if you click on a link, it CAN open in a new window, even if the "Open unrequested windows" prefernce is not checked. This preference, when it is not checked, is only supposed to stop windows from opening when the page loads, and when the page unloads. In other words, clicking on links SHOULD allow new windows to be opened.
Re comment 2 and comment 3: If 'Open unrequested windows' is not checked, it's OK to open a window if it's a direct result of a user action (e.g. clicking on <A href="something.html" target="_blank">Open a new window</A> or <INPUT type="button" onClick="window.open('a_popup.html')">), but *not* without the user specifically requesting it (e.g. <BODY onload="window.open('popup_ad.html')">).
The preference being acted upon is "dom.disable_open_during_load" Another site that exhibits this behavior is: http://www.aim.com/get_aim/express/aim_expr.adp When you click on the start button, it opens a new window for the applet (unless, of course, you have set "dom.disable_open_during_load" to true.) In principal, believe that Russell is correct. However, there is a grey area here. In the AIM express case, clicking on the button does a: window.open("http://toc.oscar.aol.com/tic.html".....). This window then attemps to trigger yet another window with the applet in it... a violation of the principal behind disable_open_during_load. It is possible that pogo is doing something similar.
Alright, I've been thinking about this bug. It seems that it is going to be impossible to actually fix this bug since legitimate sites like aim.com cannot be easily differentiated from ads that are being opened during load. Hopefully as Mozilla becomes more popular, sites like aim and pogo will change how they load their applets so that they are directly opened rather than through a second window. However, in the meantime, I think that there are two features that could be added to Mozilla that will help this problem. The first would be some way to tell when a page is trying to load in the background. This way when we click on a link like aim's or pogo's, and nothing happens, we can tell that a page is trying to be loaded. I'm not sure how this would work exactly, perhaps a sound or some small visual icon at the top of the screen could be displayed when a new window tries to open. Second, there should be a way to have specific servers that are allowed or not allowed to open pages on load. That way, I could disable all unrequested windows, unless they are being requested from aim.com or pogo.com. Anyways, these features probably won't be able to be initiated before 1.0, but I still think that we should consider them.
"Open unrequested windows" should have a clearer name/description. Maybe: "Create more windows when the page loads or unloads" There are several mozilla features that I would like to see work on sites: I'd like to block images based on a URL regexp, and I'd like to block window.open based on server domain information (or even onto IE like zones)
I agree with Jerry's suggestion for a clearer name for "Open unrequested windows" Jerry, regexp matching URLs for img blocking is Bug 78104. Can someone mark this bug something other than unconfirmed? Sounds like this should be resolved wontfix (too bad), unless someone can determine that the original case does not fall into Brian's grey area from Comment 5.
Can't Mozilla check to see who the caller of window.open is (using the already-existing security infrastructure), and if it is the Java plug-in, let the call pass through regardless of the setting of the preference? A Java applet can already create a pure-java pop-up advertisement (using JFrame, Dialog, JWindow, etc.). It shouldn't matter whether the applet is using LiveConnect or a pure-Java solution; the preference should work uniformly.
I am an engineer at pogo. I think the way we open the described window is by setting an invisible frame in our first applet's frameset to a page that uses javascript to open the second window. This rigamarole is necessary due to the lamentable lack of a pure-Java way to open a browser window of a specified width and height. As for a way to have the popup ad killer but still enable this to work, hmm, not sure if that's going to be possible. Speaking as someone who would like pogo to be reliable, we at least need a way to detect that our window has been supressed. Then we could use the native Java window-opening call, even if it was the wrong size.
Why are we debating this? Fix the #%#$ing thing!! I argee with #4, and I think everybody who saw the feature and unchecked the box argees with #4. If we are forced to check and uncheck this box every time I go to some site that want to use JavaScript a bit, or some site that want 10 popups, then the feature is ---USELESS---! Changing the name of the feature DOES NOT fix the problem! As far as the AIM example in #5, this is an example of --BAD CODING--. Why would you have this first useless window just hanging there acting as a parent of the other windows? It even implies how sloppy a job it is by putting this warning on the window to not close it. Why not go straight to the AIM login screen window? Wouldn't this be easier for the user? I'll say screw the bad example and fix the problem for 99% of the sites that don't have multiple window popups when you click a link. (Sometimes I wonder about some of the trivial debates in the bug comments...)
This bug could be caused because of the method the Java plugin uses to open a new window. Many plugins use nsIPluginManager::GetURL (for XPCOM style like Java) and NPN_GetURL (for NPAPI style) to evaulate Javascript and tell the browser to open an URL in a certain target window. Depending on how this is being used, results may differ with different preferences turned on. For example, when the 'target' argument is not NULL, we use the nsILinkHandler interface which I think is the same used for anchor-type links.
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
I recommend that this bug be resolved wontfix. It's unneeded. Yahoo Games works fine in Mozilla 1.1 alpha with Sun Java 1.4. That shows that Mozilla can load Java game applets without supporting the method used by Pogo. Besides, wouldn't a fix for this bug create yet another way for advertisers to bypass the "do not open unrequested windows" preference?
URL: http://www.pogo.com → http://www.pogo.com/
Hardware: PC → All
I think I've bumped into this bug a couple of times. One example is the site http://www.permatex.com/MSDS_data/msdsidx.asp where, if I try to query the MSDS database it won't work if I have chosen not to open unrequested windows. I think it's a bug; I requested the window, and it still didn't open. But I get the point about this potentially providing a point of entry for popup ads. Personally, I would be happy to be able to turn on, turn off the unrequested windows option as required (until a better workaround comes along) without having to go edit -> preferences etc. Or, can we have a signal on the toolbar that someone is trying to open a window, which we can then accept or ignore as we wish? Call it a pager. (web, page, pager...man, I need more coffee), an alert that your attention is sought. I can then click on it and accept the window or delete the alert or ignore all future alerts from that site.
If this bug is fixed _correctly_, then advertisers won't be able to bypass the "open unrequested windows" preference. The reason is that the window is requested, you must click on a link for it to open. Many people have expressed a desire to see some sort of toolbar that allows you to easily change the "open unrequested windows" preference. You can go to <a href = "http://www.xulplanet.com/downloads/view.cgi?category=applications&view=prefbar">http://www.xulplanet.com/downloads/view.cgi?category=applications&view=prefbar</a>, and install the application prefenece toolbar, then customize it to display the onLoad Popups preference. This should only be a temporary workaround though.
-->plugins, future
Assignee: joe.chou → peterl
Component: OJI → Plug-ins
Priority: -- → P5
QA Contact: pmac → shrir
Target Milestone: --- → Future
I'm sorry, but the milestone for this --BUG-- is a joke, right? I've already posted my vote for this bug to be a blocker for Bug 92997 (Bugs that make Mozilla advocacy harder). As I pointed before, not fixing this makes the "popup blocker" useless.
Summary: New windows are not opened in java applets if "open unrequested windows" preference is not selected → java can't open window in response to click (when opening unrequested windows is disabled)
Severity: minor → normal
--->WONTFIX The browser's pref can not be controled in Java in this case. Plugins are native code and there are many ways we can not stop a window from being be opened.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
...actually, I think this is a dup of bug 150340
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
*** This bug has been marked as a duplicate of 150340 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
Actully, wouldn't bug 150340 be a duplicate of this bug, as this bug was reported first? Not that it really matters, but I do hope that the other bug is not marked as WONTFIX as well. I think that this is an important bug and needs to be fixed. As for this bug being marked wontfix, the issue is not that windows are opened when they shouldn't be. The issue is that windows that are requested are not opened when they should be.
I'd like to second Stephen's comments (#22) and I don't agree with Peter's comments over in Bug 150340 (#7) with regard to not using this preference at all. I LIKE being able to turn off popups. I think its behaviour just needs a little polishing, that's all. Mostly I'd just like a signal that lets me know Mozilla is refusing an (un)requested window, so if I'm expecting one, I can do something about it. ie. I'm repeating comments #6 and #15.
.
Status: RESOLVED → VERIFIED
Oh yeah...that's nice. Just ignore the @*%#ing bug and mark it as WONTFIX. We aren't talking about plugins here. We are talking about regular HTML code. Right now, Mozilla blocks basically any OnWhatever statement from opening a window. We just want that changed a little so that OnClick and a few other events can be allowed to open a window. We're talking about MODIFYING A FEW 'IF' STATEMENTS! If it's one thing I can't stand about the Mozilla project, it's the anal-retentive programmers behind it. I acknowledge that you do a lot of hard work on your own free time, and we appreciate that, but I don't appreciate all of the unnessesary politics behind it. Just look at bug 92997 which contains a bunch of the "dumb" bugs that makes Mozilla's programmers look like idiots. I want Mozilla to follow strict HTML standards, but I also want Mozilla to do as it advertizes. **** it. Let me code the goddamn thing! Just tell me where the Open Requested Windows variable gets applied and I'll put out a patch. (No wonder JWZ quit out of this project...)
If this bug is so easy to fix, why hasn't anyone attached a patch? The code that checks for the pref is located in nsGlobalWindow.cpp. Overburdened Netscape engineers love patches from the open source community to fix their bugs. However, I don't think this is that easy to fix because bug 150340 is about us not always obeying the pref. So which way should it go? How about yet another pref? It seems that someone is always not going to be happy. It may also be difficult to tell inside DOM code that it was a plugin that opened the window. Since the UI for this Mozilla feature has been intentional removed from Netscape, it is difficult to justify wasting any of my company's resources on fixing related bugs. There are plenty of other crashers on my plate which are much more important than a pref Netscape customers will probably never discover!
> If this bug is so easy to fix, why hasn't anyone attached a patch? The code > that checks for the pref is located in nsGlobalWindow.cpp. Overburdened > Netscape engineers love patches from the open source community to fix their > bugs. Yes, and this I agree with. Unforunately, a project this large hasn't quite got the open-source steampower as Linux. And hey, this is a very large project, so it's hard for one man to learn. So, I at least do my part of reporting bugs and arguing about Mozilla politics. (And I will look at that cpp file...) > However, I don't think this is that easy to fix because bug 150340 is about us > not always obeying the pref. So which way should it go? How about yet another > pref? It seems that someone is always not going to be happy. It may also be > difficult to tell inside DOM code that it was a plugin that opened the window. That's fine. Fix the OnClick first. You guys have a tedancy to overplan, and then get lost in that overplanning, and write the whole project off when a simple fix will do. Yes, it may not work with plugins, but at least fix what can be fixed first. As far as the people that won't be happy, worry about them later. > Since the UI for this Mozilla feature has been intentional removed from > Netscape, it is difficult to justify wasting any of my company's resources on > fixing related bugs. There are plenty of other crashers on my plate which are > much more important than a pref Netscape customers will probably never > discover! Oh, I see. So all of that talk about Mozilla not being AOL was BS, right? If it's not AOL/Netscape, it's not priority. In fact, it doesn't even get fixed. Contrary to popular belief, Netscape is not Mozilla, and there's a great many people who prefer Mozilla to Netscape, mainly because of the ad blocking features such as these. I agree that crashing bugs should take priority, but I'm just angered at the decision to mark this as WONTFIX.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.