- Click login button in upper right corner of www.wingspanbank.com page - Fill the username and password fields with bogus data on the login page then click login button Result: Browser completely locks up

Confirmed on Linux 2000-09-15-08 (with PSM). Changing OS to All.

OK, this is interesting. If I load the login frame by itself https://www.wingspanbank.com/sessionManager/LoginJHTML.jhtml then there is no hang. but if I try to login from that frame in it's parent page https://www.wingspanbank.com/index.html then I hang (note, not a browser lock-up, the content area fails to update until I navigate to another site) Over to HTML Frames for investigation.

Agreed. For me, on build 91905, Win32, Installer, Mozilla totally locks up even when I type in a FOO for username, and then try to move focus into the password. After trying to even get password to enter, it totally locks Mozilla up, and after switching applications, I can't even get focus back on Mozilla's webshell.

Based on the steps provided, I can reproduce on the mac as well. Tested on the Sept 29th build.

Marking [RTM need info]. Added crash keyword.

I have taken a look at this and I have no idea what is going on. Stopping the debugger once it hangs does provide much of a clue either. My guess that it is some networking issue, but that is just a big guess. If you switch to another app and come back it does get into GlobalWindowImpl::Focus()

I have found the problem. here is how the pages shape up for my attachment that duplicates the problem: 1) The main doc "index.html" contains a frame set with a single frame named "global" (the file is global.html) 2) The document global contains a frame a login page named "blank" (file is login.html) 3) the login doc contains a form with a submit where the target is "global" Apparently, there is a problem finding "global" when framesets are nested. The other stange part of this bug, is when I walked through with the debugger it seems to have found the global window and loaded the content and created frames, but it never draws. Although, I am not sure if the entire content is complete.

Hey Rod, just ran across that other bug that sounds a lot like this one. Don't know if it will be useful or not, but there is another testcase there: Bug 55897: Page load fails when targetting containing frame from nested frame.

I think I found another example of frameset targetting not working properly. If you go to the following site and click on the menu on the left (HomePage, Information, Pre-owned inventory...) it does not change the content. On 4.x it changes the content. Looking at the source it is a nested frameset. http://www.toyotacarlsbad.com/

This is a regression since it used to work.

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

Ron, how long ago did this work? Here is the testcase from Bug 55897 http://whis.net/framebug/index.html

I followed attachment 16691 [details] in the debugger and after it makes the request and the new document and new parser are created, the parser's OnDataAvailable never gets called. harishd thinks this may be because a listener is not hooked up correctly.

I'm pretty sure it worked in build 062608. That's probably too old to be much help. Sorry!

Yes, that bit of code about being hokey really did this in, - dup *** This bug has been marked as a duplicate of 47636 ***

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

Since this is a dup of 47636, and that's marked as being verified fixed, is it safe to say there is a regression? Tested on Delphi (a la bug 54025) and the freezing still occurs.

Nix comments above. (Grabbed an old build) Does work with 102304 on NT.

QA Contact update