55460 - alert() modal dialogues hidden somewhere behind window. Makes Browser inaccessible

Status: VERIFIED DUPLICATE of bug 56337

(Core :: DOM: Core & HTML, defect, P3)

Description

[Jacob Kjome]

This just started happening recently.

when clicking on alet boxes, I don't see any alert dialogue pop up, however, I 
then try to interact with the browser window and it is frozen by the hidden 
alert() modal dialogue.  I have to use the NT task manager to kill mozilla.

Test case coming up...

jake

Comment 1

[Jacob Kjome]

Attachment: simple testcase to show hidden modal alert() dialogues causing the browser to become inaccessible

Comment 2

[Jacob Kjome]

Minor modification to description...

A very few times, I would successfully see the alert box, but if I clicked "ok" 
and then tried it again, the previously described behavior happens.

So, this will happen about 95% of the time the first try and pretty much 100% 
the second try.

Jake

Comment 3

[Jacob Kjome]

Ok, I'm not sure what the deal is, but I just tested it again and it is working 
consistently.  No idea why.  I tried it about 10 times in a row with the same 
browser version build 2000100504 M18 on win32 and it caused the behavior of 
this bug.  

All of a sudden I tried it one more time and it is working perfectly fine????  
Very odd.

Does anyone else see this problem, at least sporadically???

Jake

Comment 4

[Jacob Kjome]

Ok, new build 2000100520 M18 win32

Clicking on the alert() links in the test case do absolutely nothing now.

The javascript console shows:

Error: invalid format character %ip
Error: uncaught exception: [Exception... 'Failure code: "-2147467259" 
nsresult "0x80004005(NS_ERROR_FAILURE)" location: "<unknown>"]

This seems to happen every few builds.  Man, this is sporadic!!!

Jake

Comment 5

[Jacob Kjome]

Ok, now I feel like I'm talking to myself here.

I added a link to my page in the URL box above.

There are two links on that page that are of particular interest:

1.  browser - lists navigator object properties of browser (alert())

2. List all links on this page - grabs all links on the page and dynamically
writes them to a new window (window.open())

Both of these take longer and longer to come up the more times they are pressed.

For instance, the first time I load up Mozilla and click the "browser" link, the
alert box come up pretty much right away.  However, successive times actually
freeze the browser because the alert() creates a modal javascript dialogue, but
it stays hidden somewhere for about 30 seconds or so.  Finall, I see it pop up
after waiting a while.

The same happens with the other link.  However, it seems that sometimes, for the
window.open() links, I have to mouse over the toolbar buttons in order to get
the new window to display.  Keep in mind in this popup window, I do  a
window.open, set that object to a variable and open that document reference for
writing, write the generated content to the window, then close the document...so
there is a little more than just a window.open going on here.  However, this
used to pop up immediately.

There really seems to be some sort of lag right now.

It is imperative that this is found before RTM!!!!


Jake

Comment 6

[Jacob Kjome]

I found some consistency.

Please check out the javascript errors I saw in the javascript console on 10-6.

Here is how to reproduce them.

1. If Mozilla is running now, shut down all windows.  Start up a new fresh 
window.

2. Go to http://www.visi.com/~hoju/

3. click the small arrow image in the upper left hand corner next 
to "Navigation Bar".  That will minimize the navigation bar showing you a link 
that you couldn't see before underneath.

3. Click the "browser" link

4. Open the javascript console from the tasks/tools menu

5. Note the error that I described on 10-6.  You will see them there.

6. Open up a new window (ctrl/n).

7. Repeat steps 1 - 5.  The javascript errors will not occur.   You will be 
left in one of two states.  Either you will see a javascript alert() box, or 
you will get the behavior that originally caused me to file this bug, that is 
you won't see the alert dialogue, but the window will be frozen becuase it is 
either waiting for something or it is in the background.

This is a very serious bug.  javascript alerts are used frequently.  If this 
doesn't work....  Seriously, you HAVE to fix this for RTM.  Please!


jake

Comment 7

[John Bandhauer]

Confirming. I see this on NT 4 with my trunk debug build.

I can reproduce by typing -- javascript:alert('foo') -- into the url bar. We go 
into the modal dialog loop but the dialog does not show up. Clicking on the main 
window just makes a nice ding sound and events are stopped. Only recourse 
seems to be to kill the app in taskman.

I marked this dogfood because this happens when I click on the "add to sidebar" 
link on the tinderbox page. This is a critical test case for me. The fact that 
it does not work keeps me from being able to test JS components and their 
security implications.

Comment 8

[Johnny Stenback (:jst)]

Danm, could you look into this one?

Comment 9

[Asa Dotzler [:asa]]

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

Comment 10

[Michael Percy (obsolete email address)]

this also happens with links including javascript:prompt('foo!'); and 
javascript:confirm('foo?');

Seems like any modal dialog kills us. Tested with NT4 2000-10-16-09-MTrunk 
build.

Comment 11

[Jim Roskind]

Note that this is TRUNK only regresion, and does not impact the Netscape branch.
I just tried the test case with build 2000-10-17-09  (MN6 branch).

Jband: One natural dogood work-around is to use the branch to test the security
issues you are looking into.  I'm aware of one patch (re: Java to JS calls) that
landed on the trunk, and we are trying to eval it for a possible inclusion on
the branch.  Is that what you are working on?  Have you tried to drop the patch
on your branch build to test there.  What are the other issues that you are
investigating that this blocks you on (i.e., are not testable on the branch)?

Comment 12

[John Morrison]

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

Comment 13

[John Morrison]

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

Comment 14

[japh_loop]

I recommend that either the priority or severity be set higher to get the bug 
fixed/implemented quicker.

Comment 15

[Doron Rosenberg (IBM)]

hmm, I am not seeing this on win98 2000102404. However, others are (mac for
example). Nominating for mozilla0.9

Comment 16

[Michael Percy (obsolete email address)]

This is a Trunk-only bug, it does not appear on the MN6 branch. It affects all 
platforms. I am seeing it on 2000-10-25-06-Mtrunk for WinNT4. I believe it is 
foolish to target mozilla0.9 on this, as it is a javascript *crasher* and 
therefore a *security hole*. Would someone please add the "crash" keyword to 
this one? Maybe the trunk is ``low-priority'' right now but if this gets into 
the next Milestone then we will get flak, as it snuck into M18 as well.

Comment 17

[Doron Rosenberg (IBM)]

mozilla0.9 is the earliest this will be done for. This does not fit the
mozilla0.6 keyword.

Comment 18

[Asa Dotzler [:asa]]

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

Comment 19

[Asa Dotzler [:asa]]

"I believe it is foolish to target mozilla0.9 on this, as it is a javascript
*crasher* and therefore a *security hole*."

[e-mail], I think you're confused about a couple of things.  First of
all, mozilla0.9 _is_ the next mozilla milestone on the road to Mozilla 1.0 (the
trunk).  Mozilla 0.6 is a branch milestone which will mirror the Netscape6
release.  I'm also unclear what steps you took in the leap from javascript
crasher to security hole.

Comment 20

[Michael Percy (obsolete email address)]

Asa, you are right that I was unclear on the Milestone numbering; I thought 
that 0.9 would defer it until "whenever we feel like getting around to it", 
which is what the P3 Priority level infers. If I reacted to that in an 
offensive manner then it was unintentional and I apologize to Doron.

As for the security issue, it is simple: The ability to *anonymously* execute 
arbitrary code on *trusting systems* comes with it the obligation to implement 
the security for that execution correctly. If a script kiddie has the ability 
to crash a browser by entering some simple javascript code, he will cheerfully 
send people to crash and hang for the simple joy of doing it -- I think we all 
know that (anyone here fall victim to the [img src="C:\CON\CON"] IE crasher? I 
know I did).

So, yes, javascript crashers are security holes, if for no other reason than 
they allow anyone with a web page (or a javascript: URL) to crash Mozilla.

Comment 21

[Jesse Ruderman]

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

Comment 22

[Asa Dotzler [:asa]]

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

Comment 23

[Jesse Ruderman]

Adding crash keyword, and also top100 because this happens with search 
bookmarklets.  I second jband's dogfood nomination, because this bug makes it 
difficult to test other javascript/dom bugs, look for new bugs, and add sidebar 
panels (bug 56337).

Comment 24

[Jesse Ruderman]

Fixed in bug 56337.  Yay :)

*** This bug has been marked as a duplicate of 56337 ***

Comment 25

[Prashant Desale]

Verified Duplicate.