356866 - java showDocument() call that results in a new window being opened, causes later java showDocument() calls to be queued

Status: RESOLVED FIXED

(Core Graveyard :: Java: OJI, defect)

Description

[jeff oconnell]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7


we've discovered a problem in firefox 1.5.0.x on macos 10.4 where when 
an applet has made a call to showDocument() that opens a new window, 
subsequent calls to showDocument() are queued up, i.e. later showDocument() 
calls returns cleanly, but the requested URL events are blocked until the
popup window is closed.

i've created a page and test applet which reliably reproduces this problem.

if you need more information, please feel free to contact me. 

Reproducible: Always

Steps to Reproduce:
please see http://rulez.com/showdocument/README.txt for testing information.

Comment 1

[jeff oconnell]

just to be clear:

i have a readme here:
http://rulez.com/showdocument/README.txt

a reproducable case here:
http://rulez.com/showdocument/web/index.html

and sample java source here;
http://rulez.com/showdocument/src/MyApplet.java

Comment 2

[Stefan [:stefanh]]

Hmm, does it work in Firefox 2 RC 2?

Comment 3

[jeff oconnell]

rc2 is not available to me yet, but if it's released this evening as expected, i'll test tomorrow morning.

Comment 4

[Marcia Knous [:marcia]]

We are actually testing and about to release FF RC3, which can be downloaded here:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2.0rc3-candidates/rc1.

You should test that build if possible.

(In reply to comment #3)
> rc2 is not available to me yet, but if it's released this evening as expected,
> i'll test tomorrow morning.
> 

Comment 5

[jeff oconnell]

okay, i just ran a test with FF 2 RC3 and have some interesting results:

1. if new pages are targetted to tabs, the subsequent showDocument() calls work as expected.
2. if new pages are targetted to a new window, the showDocument() calls are queued.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Jeff, your example is a bit confusing -- none of the "open popup"
buttons are needed.  But I'm able to reproduce the problem in all
Mozilla.org Carbon-based browsers (e.g. Firefox 1.5.0.7, Firefox 2.0
RC 2, and Seamonkey 1.0.5).  It doesn't happen in Camino.

(You need (of course) to allow rulez.com to popup windows.  And in
Firefox 2.0 you also need to specify that new pages should be opened
in a new window (which isn't the default).)

You're right that this problem is related to bug 311843 (specifically
to the problem reported at
https://bugzilla.mozilla.org/show_bug.cgi?id=311843#c13), but it's not
a dup.

Basically, this is (along with
https://bugzilla.mozilla.org/show_bug.cgi?id=311843#c13) another very
obscure (i.e. rarely encountered) side effect of a fix in the Java
Embedding Plugin for an obscure bug in Mozilla.org's Carbon-based
browsers -- they don't pause between multiple JavaScript "alert"
dialogs launched using Java showDocument().

I found a way to narrow the scope of my fix to get around
https://bugzilla.mozilla.org/show_bug.cgi?id=311843#c13.  I'll be
looking for a way to narrow it still further, to get around this bug,
too.

Comment 7

[jeff oconnell]

steven,

i've removed the "open popup" links from the frames.
they we left over from previous attempts at reproducing the problem.

i'm glad you understand the problem, and thanks for your swift attention.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

I've just released a new version of the JEP (0.9.6) that resolves this
problem.  See bug 364158.  Please try it out.

Comment 9

[jeff oconnell]

thanks steven.

i just tried to new JEP with my original test case - as well as in a couple other context
where i saw the bug - and had no problems.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

Glad to hear my fix solved your problem.  Thanks for letting me know.

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

FIXED by the checkin for bug 364158.