Overview Description: Browser freezes when typing TAB in location bar Steps to Reproduce: 1) launch browser 2) type www.yahoo.com in location bar; hit Enter 3) let page load 4) hit TAB Actual Results: Browser freezes (will not respond to any UI events) Expected Results: do what TAB does (the final behaviour is not for certain, but it should begin to move the next focussable item in the content or hightlight the contents of the location bar (depending on what is currently implemented)). Reproducibility: always Build Date & Platform Bug Found: 2000042508 win95 (hand installed -- installer busted) Additional Builds and Platforms Tested On: does NOT occur on 2000042508 linux mac not out yet today (doing smoketests right now) Additional Information: This message shows in the console on initial load of the browser: nsNativeComponentLoader: SelfRegisterDll(C:\TEMP\ASDF\BIN\components\ender.dll) Load FAILED with error: error 31 (but isn't ender.dll obsolete -- now editor.dll. Is that a separate bug?)

I'm setting this to blocker. It is very easy to trigger this (I hit it ~4 times before I realized what the problem was).

Odd... I'm not seeing this problem with the -talkback.zip version of the same build on WinNT 4.0 -- nothing happens after typing TAB in the URL bar, and the browser operates normally thereafter. In some UI freezes I've seen, using ALT+B to get to the bookmarks menu, then loading a new page, clears up the problem. Does that apply here?

Hmm. This happens 100% of the time for me (comm. build win 95). This is a complete freeze, so no keystrokes or mouse events work (hence no workaround). ... just as I was typing this, mozilla crashed in the background (while it was in this frozen state). Crash is in RDF.DLL. Talkback trace to follow.

See http://cyclone/reports/SingleIncidentInfo.cfm?dynamicBBID=9391052 in an infinite loop at nsEventStateManager::GetNextTabIndex [d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line 1827] I can reproduce this every time.

This is not an editor problem. Here's the stack during the freeze: ... 0B68A500 PPC 1B0348BC nsEventStateManager::ShiftFocus(int)+0066C 0B68A400 PPC 1B0346D4 nsEventStateManager::ShiftFocus(int)+00484 0B68A300 PPC 1B035B6C nsEventStateManager::GetNextTabbableContent(nsIContent*, nsIFram e*, int, nsIContent**)+01084 0B689F60 PPC 1B036388 nsEventStateManager::GetNextTabIndex(nsIContent*, int)+0014C 0B689D90 PPC 1B036388 nsEventStateManager::GetNextTabIndex(nsIContent*, int)+0014C 0B689BC0 PPC 1B036388 nsEventStateManager::GetNextTabIndex(nsIContent*, int)+0014C 0B6899F0 PPC 1B036388 nsEventStateManager::GetNextTabIndex(nsIContent*, int)+0014C 0B689820 PPC 1B036388 nsEventStateManager::GetNextTabIndex(nsIContent*, int)+0014C 0B689650 PPC 1B036388 nsEventStateManager::GetNextTabIndex(nsIContent*, int)+0014C 0B689480 PPC 1B036388 nsEventStateManager::GetNextTabIndex(nsIContent*, int)+0014C 0B6892B0 PPC 1B036388 nsEventStateManager::GetNextTabIndex(nsIContent*, int)+0014C 0B6890E0 PPC 1B036388 nsEventStateManager::GetNextTabIndex(nsIContent*, int)+0014C 0B688F10 PPC 1B036388 nsEventStateManager::GetNextTabIndex(nsIContent*, int)+0014C 0B688D40 PPC 1B036278 nsEventStateManager::GetNextTabIndex(nsIContent*, int)+0003C 0B688B70 PPC 1C3929A0 nsXULElement::ChildCount(int&) const+00024 0B688B20 PPC 1C399CE0 nsXULElement::EnsureContentsGenerated() const+00218 0B688A90 PPC 1C3075C4 nsXULDocument::CreateContents(nsIContent*)+0015C 0B688A30 PPC 1C3D634C nsXULTemplateBuilder::CreateContents(nsIContent*)+ 00088 0B6889E0 PPC 1C3DFA44 nsXULTemplateBuilder::CreateTemplateAndContainerContents(nsICont ent*, nsIContent**, int*)+00204 0B6888C0 PPC 1C3E00B0 nsXULTemplateBuilder::CreateContainerContents(nsIContent*, nsIRD FResource*, int, nsIContent**, int*)+00560 0B688760 PPC 1C3DA3C4 nsXULTemplateBuilder::BuildContentFromTemplate(nsIContent*, nsIC ontent*, nsIContent*, int, nsIRDFResource*, int, Match*, nsIContent**, int*)+ 00CA4 0B687CE0 PPC 1C3DA930 nsXULTemplateBuilder::BuildContentFromTemplate(nsIContent*, nsIC ontent*, nsIContent*, int, nsIRDFResource*, int, Match*, nsIContent**, int*)+ 01210 0B687260 PPC 1C3E1344 nsXULTemplateBuilder::CheckContainer(nsIRDFResource* , int*, int* )+001FC 0B687190 PPC 1C2E62F0 CompositeEnumeratorImpl::HasMoreElements(int*)+000B4 0B6870F0 PPC 1C2E6A7C CompositeArcsInOutEnumeratorImpl::GetEnumerator(nsIRDFDataSource *, nsISimpleEnumerator**)+00098 0B687080 PPC 1C332CA8 FileSystemDataSource::ArcLabelsOut(nsIRDFResource*, nsISimpleEnu merator**)+004C4 0B686F00 PPC 1C906E80 nsFileSpec::nsFileSpec(const nsFileURL&)+00030

I'm not seeing this on Linux.

giving to waterson. there's lots of XULTemplateBuilder stuff on the stack.

John -- your observation about ender.dll appears to be covered by bug 37125, "ender.dll is dead, but it is still packaged in *-talkback.zip"

Yes. I filed that bug separately, and it is just a packaging issue. So, ignore that mention of it above.

adding [nsbeta2+] per pdt.

Removing smoketest/blocker in favour of crash; workaround is to not use TAB while in the location bar.

How can I figure out where focus goes after pressing TAB in the URL bar?

Allright, this appears to be due to a combination of things. nsEventStateManager::GetNextTabIndex() is crawling the entire content model to find the next tab index. This trips over the bookmarks menu, and if you've got a "file:" or "ftp:" bookmark in that menu, then it'll build up the *entire* content model (e.g., by reading the entire FTP site or directory hierarchy).

rjc: this is due to bad interaction between the new FTP/file datasource and the focus-finding code. The code that tries to find the next focused element does a content tree walk, and is walking into FTP and file folders in the personal toolbar. The patch I've attached above will fix the problem, but after talking with XPToolkit guys, they think that the right thing to do is to treat FTP directories as leaves in menus. Having FTP/file directories *not* be leaves will cause a whole class of other problems; e.g., . if somebody calls getElementsByAttribute() on the root document, it will open every single file & FTP directory. . you'll need to worry about popping up an auth dialog in the middle of menu traversal. I'm punting this bug to you: if you like, you can check in the fix to the ESM, but realize that it's only a band-aid.

I think that we still need to apply this fix to prevent the ESM from over-eagerly crawling content; otherwise, even without HTTP-INDEX, it can still heavily hit the file system unnecessarily.

Can you please check in that patch? this bug is kicking my arse.

I can get into similar RDF-trawling-of-death even with this patch, by another means; try to drag a button in the main toolbar (e.g. reload, or stop), even if the button is disabled. You might need file or FTP urls in your bookmarks, still. My stack looks like: 0BFB4DC0 PPC 1EFD06D0 main+00224 0BFB4D20 PPC 1EFCECD0 main1(int, char**, nsISplashScreen*)+00810 0BFB4C20 PPC 1E180A60 nsAppShellService::Run()+00054 0BFB4BD0 PPC 1E0F5B7C nsAppShell::Run()+00040 0BFB4B90 PPC 1E0F642C nsMacMessagePump::DoMessagePump()+00044 0BFB4B40 PPC 1E0F6C48 nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 00174 0BFB4AF0 PPC 1E0F7B60 nsMacMessagePump::DoIdle(EventRecord&)+00060 0BFB4AA0 PPC 1E0F76DC nsMacMessagePump::DoMouseMove(EventRecord&)+0008C 0BFB4A50 PPC 1E0F7C00 nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort*)+0004C 0BFB4A00 PPC 1E0F26B4 nsMacMessageSink::DispatchOSEvent(EventRecord&, GrafPort*)+00048 0BFB49C0 PPC 1E0EBF30 nsMacWindow::HandleOSEvent(EventRecord&)+00038 0BFB4980 PPC 1E0ED0F0 nsMacEventHandler::HandleOSEvent(EventRecord&)+001C0 0BFB4930 PPC 1E0EEFDC nsMacEventHandler::HandleMouseMoveEvent(EventRecord& )+000C0 0BFB4890 PPC 1E0CD0BC nsWindow::DispatchMouseEvent(nsMouseEvent&)+00060 0BFB4830 PPC 1E0CCF58 nsWindow::DispatchWindowEvent(nsGUIEvent&)+00028 0BFB47F0 PPC 1E0CCE60 nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus& )+000B8 0BFB47A0 PPC 1BF11FBC HandleEvent(nsGUIEvent*)+00064 0BFB4750 PPC 1BF1E294 nsViewManager2::DispatchEvent(nsGUIEvent*, nsEventStatus*)+007DC 0BFB4550 PPC 1BF1483C nsView::HandleEvent(nsGUIEvent*, unsigned int, nsEventStatus*, int&)+00224 0BFB44D0 PPC 1C42B384 PresShell::HandleEvent(nsIView*, nsGUIEvent*, nsEventStatus*, int&)+0032C 0BFB4430 PPC 1C42B8A8 PresShell::HandleEventInternal(nsEvent*, nsIView*, nsEventStatus*)+001A4 0BFB43D0 PPC 1C8A2DE0 NSGetModule+548D4 0BFB4380 PPC 1C40988C nsFrame::HandleEvent(nsIPresContext*, nsGUIEvent*, nsEventStatus*)+0034C 0BFB42C0 PPC 1C40C844 nsFrame::HandleDrag(nsIPresContext*, nsGUIEvent*, nsEventStatus*)+00498 0BFB41F0 PPC 1C881D38 NSGetModule+3382C 0BFB4140 PPC 1C8819CC NSGetModule+334C0 0BFB4100 PPC 1C882640 NSGetModule+34134 0BFB4020 PPC 1C89148C NSGetModule+42F80 0BFB3E30 PPC 1C88C394 NSGetModule+3DE88 0BFB3CE0 PPC 1C88B7A0 NSGetModule+3D294 0BFB3C30 PPC 1C8B5470 nsGeneratedContentIterator::Next()+00178 0BFB3BC0 PPC 1C8B4894 NSGetModule+66388 0BFB3A90 PPC 1C8B24BC NSGetModule+63FB0 0BFB39C0 PPC 1CCB9B70 nsXULElement::ChildAt(int, nsIContent*&) const+00024 0BFB3950 PPC 1CCC0E1C nsXULElement::EnsureContentsGenerated() const+00218 0BFB38C0 PPC 1CC2D4E4 nsXULDocument::CreateContents(nsIContent*)+0015C 0BFB3860 PPC 1CCFFB28 nsXULTemplateBuilder::CreateContents(nsIContent*)+ 00088 0BFB3810 PPC 1CD08F68 nsXULTemplateBuilder::CreateTemplateAndContainerContents(nsIContent*, nsIContent* *, int*)+00204 0BFB36F0 PPC 1CD0937C nsXULTemplateBuilder::CreateContainerContents(nsIContent*, nsIRDFResource*, int, nsIContent**, int*)+00308 and a little time later at 0BFB4DC0 PPC 1EFD06D0 main+00224 0BFB4D20 PPC 1EFCECD0 main1(int, char**, nsISplashScreen*)+00810 0BFB4C20 PPC 1E180A60 nsAppShellService::Run()+00054 0BFB4BD0 PPC 1E0F5B7C nsAppShell::Run()+00040 0BFB4B90 PPC 1E0F642C nsMacMessagePump::DoMessagePump()+00044 0BFB4B40 PPC 1E0F6C48 nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 00174 0BFB4AF0 PPC 1E0F7B60 nsMacMessagePump::DoIdle(EventRecord&)+00060 0BFB4AA0 PPC 1E0F76DC nsMacMessagePump::DoMouseMove(EventRecord&)+0008C 0BFB4A50 PPC 1E0F7C00 nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort *)+0004C 0BFB4A00 PPC 1E0F26B4 nsMacMessageSink::DispatchOSEvent(EventRecord&, GrafPort*)+00048 0BFB49C0 PPC 1E0EBF30 nsMacWindow::HandleOSEvent(EventRecord&)+00038 0BFB4980 PPC 1E0ED0F0 nsMacEventHandler::HandleOSEvent(EventRecord&)+001C0 0BFB4930 PPC 1E0EEFDC nsMacEventHandler::HandleMouseMoveEvent(EventRecord& )+000C0 0BFB4890 PPC 1E0CD0BC nsWindow::DispatchMouseEvent(nsMouseEvent&)+00060 0BFB4830 PPC 1E0CCF58 nsWindow::DispatchWindowEvent(nsGUIEvent&)+00028 0BFB47F0 PPC 1E0CCE60 nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus& )+000B8 0BFB47A0 PPC 1BF11FBC HandleEvent(nsGUIEvent*)+00064 0BFB4750 PPC 1BF1E294 nsViewManager2::DispatchEvent(nsGUIEvent*, nsEventStatus*)+007DC 0BFB4550 PPC 1BF1483C nsView::HandleEvent(nsGUIEvent*, unsigned int, nsEventStatus*, i nt&)+00224 0BFB44D0 PPC 1C42B384 PresShell::HandleEvent(nsIView*, nsGUIEvent*, nsEventStatus*, in t&)+0032C 0BFB4430 PPC 1C42B8A8 PresShell::HandleEventInternal(nsEvent*, nsIView*, nsEventStatus *)+001A4 0BFB43D0 PPC 1C8A2DE0 nsButtonBoxFrame::HandleEvent(nsIPresContext*, nsGUIEvent*, nsEv entStatus*)+000B4 0BFB4380 PPC 1C40988C nsFrame::HandleEvent(nsIPresContext*, nsGUIEvent*, nsEventStatus *)+0034C 0BFB42C0 PPC 1C40C844 nsFrame::HandleDrag(nsIPresContext*, nsGUIEvent*, nsEventStatus* )+00498 0BFB41F0 PPC 1C881D38 nsSelection::HandleDrag(nsIPresContext*, nsIFrame*, nsPoint&)+00 300 0BFB4140 PPC 1C8819CC nsSelection::HandleClick(nsIContent*, unsigned int, unsigned int , int, int, int)+00088 0BFB4100 PPC 1C882640 nsSelection::TakeFocus(nsIContent*, unsigned int, unsigned int, int, int)+006F4 0BFB4020 PPC 1C89148C nsDOMSelection::Extend(nsIDOMNode*, int)+00D78 0BFB3E30 PPC 1C88C394 nsDOMSelection::selectFrames(nsIPresContext*, nsIDOMRange*, int) +009A8 0BFB3CE0 PPC 1C88B7A0 nsDOMSelection::selectFrames(nsIPresContext*, nsIContentIterator *, nsIContent*, nsIDOMRange*, nsIPresShell*, int)+002D4 0BFB3C30 PPC 1C8B5470 nsGeneratedContentIterator::Next()+00178 0BFB3BC0 PPC 1C8B4894 NSGetModule+66388 0BFB3A90 PPC 1C8B24BC NSGetModule+63FB0 0BFB39C0 PPC 1CCB9B70 nsXULElement::ChildAt(int, nsIContent*&) const+00024 0BFB3950 PPC 1CCC0E1C nsXULElement::EnsureContentsGenerated() const+00218 0BFB38C0 PPC 1CC2D4E4 nsXULDocument::CreateContents(nsIContent*)+0015C 0BFB3860 PPC 1CCFFB28 nsXULTemplateBuilder::CreateContents(nsIContent*)+ 00088 0BFB3810 PPC 1CD08F68 nsXULTemplateBuilder::CreateTemplateAndContainerContents(nsICont ent*, nsIContent**, int*)+00204 0BFB36F0 PPC 1CD09394 nsXULTemplateBuilder::CreateContainerContents(nsIContent*, nsIRD FResource*, int, nsIContent**, int*)+00320 0BFB3590 PPC 1CCF07D0 RootNode::Propogate(const InstantiationSet&, void*)+ 00064 0BFB3530 PPC 1CCF0B94 TestNode::Propogate(const InstantiationSet&, void*)+ 000F8 0BFB34A0 PPC 1CCF0ADC TestNode::Propogate(const InstantiationSet&, void*)+ 00040

Simon, if you are still seeing the problem after applying Chris' proposed fix, it smells like you are hitting upon bug # 29359.

Seach DLL loaded at startup? I don't see how that would cause this thrashing that I see.

Read "Seach DLL loaded at startup" as "over-eager content generation causing data to be fetched too aggressively".

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

verified duplicate.

Adding keyword to bugs which already show a nsbeta2 triage value in the status whiteboard so the queries don't get screwed up.