155351 - Pop-up blocking prevents window.open into _self or _top

Status: VERIFIED FIXED

(Camino Graveyard :: General, defect)

Description

[Jørgen Nørgaard]

On the URL, from hardware choose f.ex. monitors. Does not change.

In mozilla it does change.

Have selected to block uninvited pop ups.

(this is a nightly build)

Comment 1

[Winnie Lam]

This works for me using the 07-02 build.

Comment 2

[Jørgen Nørgaard]

Well, works for me UNTIL I have visited a site like thehungersite.com and
accepted chimera's offer to prevent popup windows.

The javascript appears to be:

function jumptourl(myvalue) {
  var mylink;
  mylink = myvalue.options[myvalue.selectedIndex].value
  if (mylink != "")
    {
      myvalue.selectedIndex=0;
      window.open(mylink,"_self");
    }
}

This just replaces the current window? Not really an uninvited popup window.
Slightly cumbersome code perhaps.

(latest nightly, Gecko/20020702)

Comment 3

[Stephane Moureau]

It was 153089, they mark it as solved ?!

Comment 4

[Greg K.]

Confirmed using Chimera/20020708.

1. Configure Chimera to not block pop-ups
2. Access the URL and choose "Monitors" from Hardward. It works.
3. Visit [thehungersite.com] and agree that Chimera should block pop-ups
4. Repeat step 2 and note the failure.

Revising Summary. It appears "window.open(mylink,"_self");" is the problem code.
Chimera is interpreting this as an attempt to open a new window, but it isn't.

This works as expected in FizzillaCFM/2002062203 with unrequested window opening
disallowed.

Comment 5

[Greg K.]

(Stephane, the problem in bug 153089 now WorksForMe using Chimera/20020708.)

Comment 6

[wkfx2003-bugzilla]

I think
[window.open(mylink,"_self")]
is not "popup" and hence should not be blocked.

Comment 7

[webj2]

The popup blocker also blocks popup windows in response to clicking in a Flash applet.

Comment 8

[Jørgen Nørgaard]

On http://www.info.apple.com/usen/cip/index.html the system menu has action set
to open into _top.

When having enabled popup blocking selecting in the menu does not go to the
selected page.

Build ID: 2002102104

Comment 9

[kaldari]

*** Bug 160707 has been marked as a duplicate of this bug. ***

Comment 10

[kaldari]

*** Bug 168109 has been marked as a duplicate of this bug. ***

Comment 11

[kaldari]

*** Bug 181343 has been marked as a duplicate of this bug. ***

Comment 12

[Josh Whitver]

Is anyone looking into a code fix for this?  I'm seeing a lot of bugs being
marked as duplicates, but little activity related to fixing it.

Comment 13

[kaldari]

*** Bug 180560 has been marked as a duplicate of this bug. ***

Comment 14

[S Woodside]

re comment 12: it's still not clear to me at least what the problem is. Do you
have to turn off popup blocking then let it be turned on to get this bug? Is the
bug that chimera is blocking page loads that it would normally let through
because they have target = _self ? I don't get it.

Comment 15

[Joshua Ochs]

The problem is once you use Chimera's interface to block popup ads, the
Javascript methods listed no longer function. This line appears to be added when
popup blocking is selected in Chimera:

user_pref("dom.disable_open_click_delay", 1000);

When the usual is this:

user_pref("dom.disable_open_click_delay", 0);

When set back to 0, popup blocking functions normally as does JavaScript (at
least in my experience).

Comment 16

[kaldari]

Removing dependancy on bug 155094. This bug has nothing to do with pop-up
blocking UI. Pop-up blocking should never block window.open unless it's on an
onload or onunload event. Also, it should probably not block window.open _self
or window.open _top anyway, as these actions do not create pop-up windows.
Perhaps someone tried to created an exception for window.open _top and _self so
that they didn't get blocked by pop-up blocking, but somehow it had the opposite
effect and ended up always blocking window.open _top and _self even if they
weren't on onload or onunload events. I'll try to create a testcase to better
explain what's going on here...

Comment 17

[kaldari]

Attachment: testcase

Comment 18

[kaldari]

BTW, this bug has been inconsistant for me lately. On both the MacWorld page and
the Apple page, the select lists sometimes work, sometimes they don't. For
example, I'll try selecting "Hardware" from the MacWorld menu. The first couple
of times, it will do absolutely nothing, in fact the menu even reverts back to
the first option instead of the one I chose (thus onChange probably doesn't get
called). Then on the 3rd or 4th try it will work just fine and load the new page
(and I won't be able to reproduce the bug again). 

Perhaps this bug is really that selecting an option from a select list doesn't
always trigger the onChange event and somehow this is caused by pop-up blocking?

If some more people could try out the test case I attached and report the
behavior they experience, maybe we could narrow this bug down some more.

Comment 19

[kaldari]

After some digging around the Mozilla site:

"When the dom.disable_open_click_delay pref is set to a non-zero number,
window.open will fail when called more than that number of milliseconds after a
mouse click. Setting this pref should turn off pop-up and pop-under ads that use
the onload handler of <img> tags to work around our previous window.open() filter."

So for some reason, when selecting an option from a select list, it's often
taking longer than 1 second to trigger the window.open command in the onchange
event, or perhaps it is not triggering at all. I'm going to experiment with this
pref a bit to see if I can find out which is the case.

Comment 20

[S Woodside]

that would explain why it's erratic, at least...

Comment 21

[Simon Fraser [no longer active]]

I think we should fix this.

Comment 22

[kaldari]

Also looks like using a confirm before a window.open can trigger blocking: bug
187904.

Comment 23

[Nick Levay]

This same problem is also breaking bookmarkets from a number of sites.

These are slices of javascript stored as bookmarks and used to open windows, and
pass certain info to their target pages.  Current URL, page title, selected
text, etc.

---
http://www.memestreams.net/documentation.html#bookmarklet - Blogging & Thread
discussion bookmarklets

Recommend:

javascript: (function() { javascript: TEXT='';function Meme(win){for(var
i=0;i<win.length;i++){Meme(win.frames[i])};try{TEXT+=win.document.getSelection()}catch(e){try{TEXT+=win.document.selection.createRange().text}catch(e){TEXT+=''}}}Meme(top);void(thiswindow=window.open('http://www.memestreams.net/recommend/?url='+escape(location.href)+'&topic=&title='+escape(document.title)+'&text='+escape(TEXT),'imemerecwin','status,scrollbars,width=695,height=350,left=75,top=75'));
thiswindow.focus();})()

Discuss:

javascript: (function() { javascript:
void(thiswindow=window.open('http://www.memestreams.net/thread/?url='+escape(location.href),'imemetalkwin'));
thiswindow.focus();})()

---
http://www.technorati.com/cosmos/links.html - Technorati Cosmos blog URL tracker

javascript:dT30FfN3b=new
Date();void(window.open('http://www.technorati.com/cosmos/links.html?sub=anywherew1&url='+location.href,'w'+dT30FfN3b.getTime()))

---
http://www.magnetbox.com/riaa/ - RIAA Radar

javascript:var%20index=location.href.indexOf('/-/');if(index!=-1){var%20asin=location.href.substring(index+3,index+13);}else{var%20index=location.href.indexOf('ASIN');var%20asin=location.href.substring(index+5,index+15);}void(win=window.open('http://www.magnetbox.com/riaa/check.asp?asin='+asin,'riaa','toolbar=0,location=0,directories=0,status=1,menubar=0,scrollbars=1,resizable=1,width=450,height=400'));

---

All these work fine with popup blocking in Mozilla, but not in Camino.

I have tested as recently as nightly build 2003052004.

Comment 24

[Simon Fraser [no longer active]]

->pink

Comment 25

[Mike Pinkerton (not reading bugmail)]

so if we no longer set dom.disable_open_click_delay, is that all that's required
to fix this bug?

Comment 26

[Mike Pinkerton (not reading bugmail)]

can someone answer my last question? is not setting the one pref enough?

Comment 27

[S Woodside]

According to comment 15 it should not be removed, but changed, to,
user_pref("dom.disable_open_click_delay", 0);

Someone who cares about this please confirm whether or not this fixes the problem.

Comment 28

[Jasper]

I just checked this with the testcase and when changing this line
user_pref("dom.disable_open_click_delay", 0); 
in the prefs.js a new window will open.

When the pref line is
user_pref("dom.disable_open_click_delay", 1000); 
the new window will not open.

So to answer comment 25 and comment 27, yes as far as I can tell changing 1000
into 0 will solve this issue. Please double check this.

Comment 29

[Mike Pinkerton (not reading bugmail)]

fixed. that's right. i fixed a bug. :D

Comment 30

[Mike Pinkerton (not reading bugmail)]

*** Bug 187904 has been marked as a duplicate of this bug. ***

Comment 31

[Chris Petersen]

Verified