192923 - Clicking JavaScript links stops rest of page from rendering

Status: RESOLVED DUPLICATE of bug 130265

(Core :: DOM: Navigation, defect)

Description

[osavill]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030127
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030127

Goto http://www.suade.co.uk/gallery.shtml and click on a picture before the
progress bar has reached 100%
   Result: Script text bleeds out over the main page and the rest of the page is
not loaded. 

Goto http://www.denzilgrant.com/cgi-bin/RenderPages/Render?Tables.csv?1 and
click on a price before the page has completely loaded.
   Result: The popup window in produced and renders correctly but the main page
has stopped rendering with have completed images.

These page work as expected in Opera, Konqueror and IE but not in Mozilla or
Phoenix.

Reproducible: Always

Steps to Reproduce:
1.As described in `Details'
2.
3.

Actual Results:  
As described in `Details'

Expected Results:  
Mozilla should have continued to correctly load the rest of the page from which
the java script URLs were launched

Comment 1

[Phil Schwartau]

Confirming with Mozilla trunk binary 2003021108 on WinNT. Note,
I do not have the experimental HTTP pipelining feature turned on.

Once some of the images have loaded, I clicked on one of them
(not one of the lower, empty image-boxes that had not yet loaded).

Then page loading halted completely, and the <script> element beginning

var imgArr1 = new Array(
             "/images/t/Cab/Blues Bros Stage Cut (Custom).jpg", 
                        
                               etc.
                               etc.

was rendered as text on the page. The DOM Inspector showed that the
content model had not formed, and the page did not respond to any
further mouse clicks. No errors appeared in the JavaScript Console.

Note: I saved the page locally and added a base element as follows:
<BASE HREF="http://www.suade.co.uk/">. I then loaded the page off
my local drive, and was UNABLE to reproduce the bug this way!!!

If I clicked on an image just after it appeared, and before all the
other images had loaded, the event handler for the image I clicked
worked perfectly, and brought up a child window successfully.

So this is some sort of timing issue; I don't know why we fail to 
form the content model properly when the page is loaded over the 
network. 

Note the JavaScript on this page creates large Arrays. However, I don't
think this is a JS Engine issue, reassigning to Embedding:Docshell
for further triage.

Compare bug 76495:
"Fetching a new page immediately disables user interaction with the one
being viewed [keyboard, links, scrollbars become unresponsive]"

Don't know if that is relevant at all to what's happening here. 
Note, IE6 has no trouble with the early-clicking.

Comment 2

[joakim_46]

Confirmed with build 2003021008 under Windows XP SP1.

Comment 3

[Adam Lock]

Confirming. It looks as though the link click is halting the page loading,
however this is not a regression as the same behaviour can be observed in 1.0.x
as well. My guess is that this behaviour has always been there.

The page loading is halted by a call to Stop() in InternalLoad() in response to
the link click event:

nsDocShell::InternalLoad(nsDocShell * const 0x0415f050, nsIURI * 0x03f82128,
nsIURI * 0x03964cd8, nsISupports * 0x00000000, int 0x00000001, const unsigned
short * 0x0012f6c0, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000,
unsigned int 0x00200001, nsISHEntry * 0x00000000, int 0x00000001, nsIDocShell *
* 0x00000000, nsIRequest * * 0x00000000) line 5203
nsWebShell::OnLinkClickSync(nsWebShell * const 0x0415f19c, nsIContent *
0x035f8f40, nsLinkVerb eLinkVerb_Replace, nsIURI * 0x03f82128, const unsigned
short * 0x100ebc18 gCommonEmptyBuffer, nsIInputStream * 0x00000000,
nsIInputStream * 0x00000000, nsIDocShell * * 0x00000000, nsIRequest * *
0x00000000) line 602 + 82 bytes
OnLinkClickEvent::HandleEvent() line 476
HandlePLEvent(OnLinkClickEvent * 0x03e0bb58) line 490
PL_HandleEvent(PLEvent * 0x03e0bb58) line 663 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00a72ef0) line 593 + 9 bytes
nsEventQueueImpl::ProcessPendingEvents(nsEventQueueImpl * const 0x00a72df8) line
387 + 12 bytes
nsWindow::DispatchPendingEvents() line 3729
nsWindow::ProcessMessage(unsigned int 0x00000202, unsigned int 0x00000000, long
0x024c0258, long * 0x0012fbf0) line 4089
nsWindow::WindowProc(HWND__ * 0x00040950, unsigned int 0x00000202, unsigned int
0x00000000, long 0x024c0258) line 1402 + 27 bytes
USER32! 77d67ad7()
USER32! 77d6ccd4()
USER32! 77d44455()
USER32! 77d495d5()
nsAppShellService::Run(nsAppShellService * const 0x00b33178) line 480
main1(int 0x00000001, char * * 0x002a4458, nsISupports * 0x00a57fc0) line 1273 +
32 bytes
main(int 0x00000001, char * * 0x002a4458) line 1636 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()

I don't know the best way to handle this. A javascript: link *could* replace the
page content, or it might do something benign. In either case, the only way to
know is by opening the javascript: channel and seeing if any data comes back. I
suppose it may be possible to do just that and defer the Stop until data begins
to arrive but it might be messy.

Comment 4

[osavill]

How do the other browsers out there get around this problem ? 

Comment 5

[Adam Lock]

Dupe of bug 130265 which has a fix in hand

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