233172 - window open (and popups) suppressed while using BlackDownJava

Status: RESOLVED EXPIRED

(SeaMonkey :: General, defect)

Description

[Lajos Kósa]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; hu-HU; rv:1.6) Gecko/20040113

With active pop-up window blocking, the windows version of mozilla 1.6 makes it
possible, when clicking on a javascript link that opens a pop-up window, it will
be opened; the linux version of mozilla does not open anything. This is like
Opera's pop-up blocking, where there is a possibility to enable accepting pop-up
javascript windows on user request (it would be not too bad if mozilla could do
it as well!). I don't know which way is the right, to open pop-up windows on
request or to refuse, but what the fact is: linux and windows versions act
differently.

Reproducible: Always
Steps to Reproduce:
1. Clicking on a javascript which wants to open a pop-up window (pop-up blocking
in activated)
2. 
3.

Actual Results:  
Windows: the window is opened; linux: nothing happens.

Expected Results:  
either open in both cases, or refuse in both cases

Comment 1

[Dan M]

What? Can you post a sample, please? Are you saying that the new window in
<a href="javascript:void(open('about:blank','_blank'))">
is refused on Linux builds with popup blocking enabled?

If so, beginning with which build? I notice your build string in the initial
comment isn't from a Linux build. And it's three weeks old. If this began on
Linux builds, but not Windows builds, beginning with Gecko/20040203, then it's
because of bug 197919.

In that case, oops. It's unintentional. The anchor element I described above
should be able to open a window, despite the blocker. It would have to be caused
by some difference in event handling between the two platforms that I didn't
foresee.

If I'm correct about the behaviour and build dates, would you try an experiment?
Add mousedown, then mouseup, to your dom.popup_allowed_events preference. (click
should already be allowed.) If one of those lets the window through, there's our
bug. This sounds icky to fix and I don't get to try, since I don't have a Linux
box right now. (If I've guessed incorrectly, then ignore all of this.)

Comment 2

[Boris Zbarsky [:bzbarsky]]

Are there any errors in the JS console?

Comment 3

[Lajos Kósa]

(In reply to comment #1)
Hi,

unfortunately, I don't have a linux built here either. I use in both cases the
stable build 1.6. I guess you misunderstood the problem - maybe my description
is not really clear. So.

Pop-up is not enabled (I hate it :)). Try site http://www.nemzetisport.hu/,
right side. This opens a pop-up. When pop-up is blocked in windows version, it
lets the window open, since I requested the pop-up window. In the linux version,
I am only able to open this pop-up window, when a) pop-up is enabled, or b) the
domain is under the pop-up enabled ones. I guess the window should open under
linux as well.

What do you suggest to test in this case? Under linux I use kde 3.1.4, I don't
know, if it makes the difference. Should I try under gnome, icewm, ...?

Comment 4

[Dan M]

-- Whew!
The 1.6 stable build lets bug 197919 off the hook.

-- What's happening on this site (forgive me for sticking to my smaller alphabet
as I describe the page :-) )

I don't see anything on www.nemzetisport.hu that should be considered a popup
window. The blocker should let everything through. Every link I can see that
wants to open a new window looks like this:

<a href="#" onclick="javascript:open('Popup_index.php','popup')">sportmusor</a>

An example is in the row near the top, a menu with items like forum, elofizetes,
sportlexicon ,datbank, sportmusor, etc. In that menu, sportmusor is one such
link, while (next to it) adatbank is not. (Adatbank is simply <a
href="Adatbank_index.php">.) Many links in the right column also open a window
the same way, including every link in the upper right pane entitled "24 ora
sport". The new window's name is generally 'popup', though sometimes something
else (but never unnamed or one of the reserved names).

And let me just say that the construction <a href="#"
onclick="doWhatIMeantToSayInTheHref()" is really weird.

-- Back to the problem at hand

Linux and Windows should behave the same on this site, especially with a 1.6
stable build, whose popup blocker is very simple and, I thought, behaved the
same on all platforms. If there's truly a difference, some dirty low-level
debugging is called for.

However I do notice a bug in the script on nemzetisport, or at least an
incompatibility with popup blockers. The links don't actually call window.open
directly, as I implied above. Instead they go through a script function. That
function looks like this (I reformatted it slightly for readability)

function open_doc_scroll(cime,szelesseg,magassag,ablak){
  if (typeof usrwindow != 'undefined')
    if (!usrwindow.closed)
      usrwindow.close();
  usrwindow=window.open(cime, ablak, 'toolbar=yes,scrollbars=yes,menubar=yes,'+
                        'top=0,left=0,resizable=yes,hotkeys=yes,'+
                        'width='+szelesseg+',height='+magassag);
}

note the variable |usrwindow| is never defined or referenced elsewhere (except
in another nearly identical function).

The first time this function is called, usrwindow is undefined and it works as
expected. But if the window is blocked from opening for any reason it will be
null from then on, not undefined. The second time this function is called, the
script will throw an error when it tries to reference the null object's |closed|
property. The function will exit, never having called window.open.

The popup blocker in 1.6 will block windows from opening while the page is
loading, even from legitimate user clicks (see bug 101190, the Bug of Many
Duplicates). Lajos, is it possible that you did something slightly different
when testing the linux version, and didn't notice? If popups are blocked and you
clicked on one of these links before the page had completely finished loading,
this site will break; it will never be able to open another window until you
reload the page.

Comment 5

[Lajos Kósa]

(In reply to comment #4)
Oh. That is a 'bit' like Chinese for me.;) But OK, I can imagine that this site
is really like a pile of... You know what.:) What I can suggest is that I'll
check on Saturday - as Boris requested - if there is an error message in Java
console. You know there are more sites I found this behaviour, but other
addresses I can't really give since most of them require registration. Or, there
is a site, kicker.de, when there is a soccer game in Germany live (tomorrow,
Saturday and Sunday you may check it), there is also a javascript window which
behaves the same way (called "Live Konferenz"). A few other examples are
vodafonemail.vodafone.hu, honfoglalo.hu. If you have time you may check them,
but as I said registration is a problem for you I guess - they are all in
Hungarian. That is maybe not a good language for you.;)

I suggest then to wait until I'll check my Java console under linux, I'll test
through a few sites, and report you the results.

Comment 6

[HJ]

(In reply to comment #5)
> I suggest then to wait until I'll check my Java console under linux...

Err, make that 'javascript' console. Not 'java' console! 

Also, you should check: "javascript.options.showInConsole" and
"javascript.options.strict" Make sure they are set to 'true' or there won't be
any JS error/warning displayed.

Comment 7

[Lajos Kósa]

(In reply to comment #6)
> Err, make that 'javascript' console. Not 'java' console! 

Sure.;) I meant that one.

So, here is some additional information.

It is now more interesting. I tried a few pages, and sometimes it's OK,
sometimes not! In the javascript console, there is nothing.

I tried the following ones:

1. http://valovilag.origo.hu/index.html
(right side, "Az elsõ Párbaj"
Results: first try not OK, 2nd try OK.

2. http://index.hu/politika/bulvar/moszkva0206/
(click on picture)
Results: first try OK, second try not OK.

3. https://www.bankoweb.hu/
(click on button "Bejelentkezés")
Results: not OK.

These sites I've also tested under windows, and there weren't any problems. My
mozilla is Mozilla/5.0 (X11; U; Linux i686; hu-HU; rv:1.6) Gecko/20040113.

I've tested the above with another user with newly created $HOME/.mozilla
directory with different windows manager (icewm instead of KDE), the results are
the same.

May be the reason for this the java engine I use? Now I'm using BlackDownJava 1.4.1.

Comment 8

[Dan M]

There's nothing very tricky in any of these sites.

1) valovilag.origo.hu, Az elsõ Párbaj looks like this
<a href="javascript:var w=window.open(|url|,|name|,|features|);w.focus();">

2) index.hu, the only window-opening elements I found were two pictures with
zoom icons in their lower right corners. They both borrowed a page from the
illustrious nemzetisport book of HTML:
<a href="#" onclick="window.open(|url|,|name>,|features|);return false;">

3) bankoweb, the Bejelentkezés button goes
<input value="Bejelentkezés" type="button"
       onclick="window.open(|url|,|name|,|features|);">

And I'm learning some Hungarian.
popup = false // ha erteke false, akkor popunder, ha erteke true, akkor popup
Yup.

Unlike nemzetisport, I notice nothing that would cause these sites to behave
differently on the first and second attempt to open a window. Valovilag and
Bankoweb both attempt to open popup windows as the main page is loading, but
they both look to not stumble should the attempt fail. Unlike the other two,
index.hu loads very slowly. So I'd expect more troubles on the *first* attempt.

So, I don't know. This needs to be debugged on a Linux box, which I don't have.
Most of your problems are happening on links with click handlers <a href="#"
onclick="open()"> but one is a very straightforward standard link <a
href="javascript:open()">.

I remain curious whether the event is coming through on Linux builds as a
mousedown or mouseup, rather than how it should come through (as a click, or
nothing at all). Lajos, if you'd care to try that experiment, it's easy. Type
about:config in the URL bar, scroll down to the preference
"dom.popup_allowed_events", double-click its line to edit its value, and then go
try your test pages. By default the preference should read "change click
dblclick error reset submit". mousedown and mouseup are also supported, but
disallowed by default. If you add mouseup; that is, change the pref to "mouseup
change click dblclick error reset submit" then Mozilla will also allow popup
windows on mouseup events. It'd be interesting to know if mouseup or mousedown
makes any of these sites behave better.

Comment 9

[Boris Zbarsky [:bzbarsky]]

I'm testing with a Linux build (CVS pulled at "Wed Feb  4 03:53:37 CST 2004")
and I don't see the problems described in comment 7...

Comment 10

[Lajos Kósa]

Guys, that is more than interesting. I replaced BlackDownJava 1.4.1 to Sun Java
1.4.2-b28, and I don't have problems any more.

So, it seems to be a BDJ bug, not a mozilla bug.

Comment 11

[Dan M]

A Java bug? I don't understand how Java could do that, but Java is a magnificent
beast. I'm glad you figured it out.

So in summary, it seems that with BlackDownJava 1.4.1 installed, window.open is
occasionally inappropriately suppressed by Mozilla's popup blocker. This is the
simpler, pre-bug 197919 blocker. So it would seem BDJ makes Mozilla think the
document is still loading after it has finished, or perhaps BDJ has some
JavaScript interface in which it sets timers in the active window. (And by the
way I kept forgetting that you're using that simpler popup blocker, so the
dom.popup_allowed_events pref I kept asking you to tweak wouldn't have had any
effect.)

Since it seems to be an interaction between BlackDownJava and Mozilla I guess
I'll leave this bug open. I'm adjusting the summary to hopefully catch duplicate
bug filings.

Comment 12

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 13

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.