Closed Bug 192923 Opened 22 years ago Closed 21 years ago

Clicking JavaScript links stops rest of page from rendering

Categories

(Core :: DOM: Navigation, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 130265

People

(Reporter: osavill, Assigned: adamlock)

References

()

Details

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
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.
Assignee: rogerl → adamlock
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → Embedding: Docshell
Ever confirmed: true
OS: Linux → All
QA Contact: pschwartau → adamlock
Summary: Using java script links stop the rest of the page from rendering → Clicking JavaScript links stops rest of page from rendering
Confirmed with build 2003021008 under Windows XP SP1.
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.
How do the other browsers out there get around this problem ?
Dupe of bug 130265 which has a fix in hand *** This bug has been marked as a duplicate of 130265 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.