*Summary Selecting Bookmarks|Manage Bookmarks caused a crash(crashed OS too) for me 4X in a row, but now it won't. Instead now I get a small window with absolutely nothing in it. *To Repro 0. Add some bookmarks, play around with 'em. 1. Select Bookmarks|Manage Bookmarks. 2. Wait a sec. 3. BOOM! *Build info This bug was tested with the 1999081208 builds on MacOS 8.5.1, WinNTsp4, and RHLinux6.0. This bug is reproducible on MacOS only. MacOS 8.6 was not tested at this time. *Expected Results After selecting Manage Bookmarks one should be presented with the Manage Bookmarks window and be able to go about one's merry way. *Actual Results After selecting the Manage Bookmarks menuitem, sometimes Seamonkey and the whole OS crash. I reproduced this several times. Recently however, instead of crahing I'm presented with a small window with absolutely_nothing_in_it. No column headers, no content, nothing. *Additional Info Sorry about the gratuitous use of the []'s I just didn't want it to miss anyone's radar. ccing chofmann in hopes this will make M9.

here's the stack trace from Talkback:(excuse the formatting) .__ptr_glue nsExpatTokenizer::OpenInputStream() [nsExpatTokenizer.cpp, line 530] nsExpatTokenizer::HandleExternalEntityRef() [nsExpatTokenizer.cpp, line 608] doProlog() [xmlparse.c, line 2268] prologProcessor() [xmlparse.c, line 2145] prologInitProcessor() [xmlparse.c, line 2134] XML_Parse() [xmlparse.c, line 867] nsExpatTokenizer::ParseXMLBuffer() [nsExpatTokenizer.cpp, line 287] nsExpatTokenizer::ConsumeToken() [nsExpatTokenizer.cpp, line 325] nsParser::Tokenize() [nsParser.cpp, line 1263] nsParser::ResumeParse() [nsParser.cpp, line 885] nsParser::OnDataAvailable() [nsParser.cpp, line 1168] nsDocumentBindInfo::OnDataAvailable() [nsDocLoader.cpp, line 2057] Network.shlb + 0xf30 (0x0da23f00) Network.shlb + 0x220 (0x0da231f0) PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() [nsEventQueue.cpp, line 117] EventDispatchingFunc() [nsEventQueueService.cpp, line 352] _hashEnumerate() [nsHashtable.cpp, line 81] PL_HashTableEnumerateEntries() nsHashtable::Enumerate() [nsHashtable.cpp, line 210] nsEventQueueServiceImpl::ProcessEvents() [nsEventQueueService.cpp, line 363]

Love to work on this, but my build from today crashes on startup

taking this bug for initial investigation

This is mac-specific, right? I am not able to reproduce on win32...

I was playing around on windows and saw a crash when playing with the bookmark manage dialog.. http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=12390124 the windows stack looks much different ncident ID 12390124 0x01d4d93c nsWebShell::CreateScriptEnvironment [d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 3163] nsWebShell::GetScriptGlobalObject [d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 3194] DocumentViewerImpl::Init [d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 375] nsWebShell::Embed [d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 943] nsDocumentBindInfo::OnStartRequest [d:\builds\seamonkey\mozilla\webshell\src\nsDocLoader.cpp, line 1954] nsHTTPResponseListener::FinishedResponseHeaders [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp p, line 629] nsHTTPResponseListener::OnDataAvailable [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp p, line 154] nsOnDataAvailableEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 350] nsStreamListenerEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 150] PL_HandleEvent [plevent.c, line 510] PL_ProcessPendingEvents [plevent.c, line 471] _md_EventReceiverProc [plevent.c, line 936] KERNEL32.DLL + 0x35d9 (0xbff735d9) KERNEL32.DLL + 0x2222f (0xbff9222f) 0x00638c00

should also note that this crash was not reproducable when I play some more. I also see some funny behavior in that if I click on one of the bookmarks in the the manage bookmark dialogs I launch the url that I've bookmarked in a new window, but when the page has fininshed loading it reloads the home page (http://www.mozillazine.org)

sideba shows this funky reloading behavia too. is thata 'notha bug?

more interesting stuff on the bookmark load, then reloading the home page thang. look like it only happens when clicking on the last bookmark added to bookmark list.

Somehow it gets its knickers in a knot if you try to open the same bookmark several times from the "manage bookmarks" window. I'm seeing it call nsXULDocument::RemoveChild(), which is bizarre. I'll start to prowl through the JS.

if any one can get the knots out of knickers, its waterson.

Robert, could you take a look at this bug? It seems to have to do with inline editing. To reproduce: 1. Open the Manage Bookmarks window. 2. Find a bookmark, preferably one near the top of the hierarchy (e.g., choosing a newly added bookmark would be good). 3. Single-click on the bookmark. Wait 10 sec. 4. Single-click again on the bookmark. This may open a new browser window; if it does, dismiss the window. 5. Single-click again. This will assert, because its trying to remove a node from the document object. I took a brief spin through the code in "bookmarks.js" and am not sure what's going on. It looks like you're adding and removing nodes to the DOM and something is getting screwed up.

Chris (Waterson), try this: cd \mozilla\xpfe\components\bookmarks\resources edit bookmarks.xul remove the onclick() handler from the bookmarks tree (around line #74).... make sure NOT to remove the ondblclick() handler. (On Windows) in the resources dir, "nmake /f makefile.win" to export the change into $DIST Now try it. Does that fix the problem?

Chris (Waterson) says it fixes it. Chris (Hoffman), may I have your permission to check in this simple fix to a JavaScript file?

ok on the fix. checkin. how about the wierd last bookmark page reload thing. can rjc and waterson show this to danm to see if its related to some wierd page loading behavior that we was looking at with joki today?

What's the deal here? Are onclick and ondblclick fighting for adjacent clicks, and both firing where only one should? Or is the JS in question misbehaving when given unexpected mixtures of single and double clicks? /be

Fixed. Brendan, the issue was with making changes to XUL via the DOM which hits some snags in RDF-land that need fixing at some point.

Reopening bug because it still crashes(on MAC) with the 1999081609 builds. The stack trace is different, it is no longer failing where it used to but it still crashes nonetheless. Here is a MacsBug stack trace: Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 0D8CF3D0 05652C80 PPC 0D8CE8F8 main+0002C 05652C30 PPC 0D8CE6B0 main1(int, char**)+00DA0 05652A50 PPC 0D603470 nsAppShellService::Run()+00018 05652A10 PPC 0D5C96E8 nsAppShell::Run()+00038 05652990 PPC 0D5CA1DC nsMacMessagePump::DoMessagePump()+0003C 05652940 PPC 0D5CA494 nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 00158 056528F0 PPC 0D850564 Repeater::DoRepeaters(const EventRecord&)+00030 056528B0 PPC 0D5AE1A0 nsToolkit::RepeatAction(const EventRecord&)+00048 05652860 PPC 0D7E2AD4 nsEventQueueServiceImpl::ProcessEvents()+00020 05652820 PPC 0D7DE5F8 nsHashtable::Enumerate(int (*)(nsHashKey*, void*, void*), void*) +00024 056527E0 PPC 0D8577C4 PL_HashTableEnumerateEntries+00060 05652770 PPC 0D7DDF1C _hashEnumerate(PLHashEntry*, int, void*)+00024 05652730 PPC 0D7E2A44 EventDispatchingFunc(nsHashKey*, void*, void*)+0002C 056526F0 PPC 0D7F5B34 nsEventQueueImpl::ProcessPendingEvents()+00010 056526B0 PPC 0D856BB8 PL_ProcessPendingEvents+00078 05652660 PPC 0D856C58 PL_HandleEvent+00028 05652620 PPC 0CF4A1E0 nsStreamListenerEvent::HandlePLEvent(PLEvent*)+0001C 056525D0 PPC 0CF4AEF0 nsOnDataAvailableEvent::HandleEvent()+00034 05652580 PPC 0D50115C nsDocumentBindInfo::OnDataAvailable(nsIChannel*, nsISupports*, n sIInputStream*, unsigned int, unsigned int)+000DC 05652510 PPC 0D1B8720 nsParser::OnDataAvailable(nsIChannel*, nsISupports*, nsIInputStr eam*, unsigned int, unsigned int)+001D0 056524B0 PPC 0D1B80F0 nsParser::ResumeParse(nsIDTD*, int)+00090 05652460 PPC 0D1B89D4 nsParser::Tokenize(int)+0008C 05652410 PPC 0D1D7580 nsExpatTokenizer::ConsumeToken(nsScanner&)+00068 056523C0 PPC 0D1D7454 nsExpatTokenizer::ParseXMLBuffer(const char*, unsigned int, int) +0003C 05652370 PPC 0D1DAA6C XML_Parse+0011C 05652310 PPC 0D1DD934 prologInitProcessor+00058 056522D0 PPC 0D1DD9E4 prologProcessor+0006C 05652280 PPC 0D1DDD84 doProlog+00358 056521E0 PPC 0D1D81B8 nsExpatTokenizer::HandleExternalEntityRef(void*, const char*, co nst char*, const char*, const char*)+000BC 056520F0 PPC 0D1D7E20 nsExpatTokenizer::OpenInputStream(const nsString&, const nsStrin g&, nsIInputStream**, nsString*)+00060 Return addresses on the stack Stack Addr Frame Addr ISA Caller 05652418 PPC 0D1B89D4 nsParser::Tokenize(int)+0008C 056523F4 68K 04C91F66 056523D8 056523D0 PPC 0D1B88DC nsParser::WillTokenize(int)+00028 056523C8 056523C0 PPC 0D1D7580 nsExpatTokenizer::ConsumeToken(nsScanner&)+00068 0565239C 68K 04C91F66 05652378 05652370 PPC 0D1D7454 nsExpatTokenizer::ParseXMLBuffer(const char*, unsig ned int, int)+0003C 05652338 PPC 0D8BA52C operator new(unsigned long, const std::nothrow_t&)+ 00014 05652318 05652310 PPC 0D1DAA6C XML_Parse+0011C 056522D8 056522D0 PPC 0D1DD934 prologInitProcessor+00058 056522A8 PPC 0D80AE0C nsString::Append(const char*, int)+ 000AC 05652298 68K 049DFC1A 05652288 05652280 PPC 0D1DD9E4 prologProcessor+0006C 0565224C 68K 04C96826 05652208 PPC 0D1DD4CC initializeEncoding+000C4 056521E8 056521E0 PPC 0D1DDD84 doProlog+00358 05652180 68K 04C91F66 05652164 68K 04C91F66 05652148 68K 04C91F66 05652108 05652100 PPC 0D8BB5C8 calloc+00030 056520F8 056520F0 PPC 0D1D81B8 nsExpatTokenizer::HandleExternalEntityRef(void*, co nst char*, const char*, const char*, const char*)+000BC 056520BC 68K 04C96826 056520B8 056520B0 PPC 0D808D7C nsString::nsString(eCharSize, nsIMemoryAgent*)+0002 0 05652098 05652090 PPC 0D1D7E20 nsExpatTokenizer::OpenInputStream(const nsString&, const nsString&, nsIInputStream**, nsString*)+00060 05652078 05652070 PPC 0D802CA8 nsStr::Initialize(nsStr&, eCharSize)+ 00018 05652068 05652060 PPC 0D80AA84 nsString::Assign(const unsigned short*, int)+00040 05652048 05652040 PPC 0D84ED84 NS_OpenURI(nsIInputStream**, nsIURI*)+ 00018

clearing fixed resolution, cc'ing leger

I should state that I was unable to reproduce the assert on windows following waterson's previous directions.

This crash is different, and far away from RDF. Looks like the XML parser maybe... Re-assigning to Nisheeth. (Sorry, Nisheeth!)

Also cc'ing Gagan, as its getting to NS_OpenURI (so, maybe Necko).

Claudius, does this happen with the original set of repro instructions? Any chance I could get you to narrow stuff down a bit?

I can reproduce this crash merely by running apprunner and selecting "Bookmarks | Manage Bookmarks".

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

To answer waterson's question. Like I said, following your repro directions on windows works w/o problem on WinNT. I originally wrote this as a Mac bug however. Following my initial repro directions still crashes - just differently, on Mac. Niseeth, this is really a dupe of bug 10703, that's not a typo? I see the XML parser calls but wouldn't other stuff be crashing too, not just Manage Bookmarks?

Necko currently does not support blocking reads on HTTP urls. It seems like the bookmarks XML file is trying to load up an external DTD or external entity with an http URL leading to the crash in Necko. Robert, if that is the case, then this bug is a duplicate of 10703. Otherwise, I goofed and we should re-open this bug.

I'm not sure what its trying to load. Its probably worthwhile for something to check. Note that this crasher is relatively new in appearing.

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

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

I am reopening this bug because its not a duplicate of 10703. I can't take a look at this till Friday night, though, because I am away for an XML demo. If somebody in Necko land can take over this bug for the next two days, that would be great. Otherwise, I'll work on this on Saturday.

So, it sounds like Win as well as Mac has a problem here, yes? claudius, can we consider a release note for M9?

This is currently only a MAC issue as labeled. The Win32 issues mentioned earlier appear fixed. I will check weekend builds for a fix, absent that I will write a release note for Monday.

It's all my fault. sdagley and nisheeth told me that the 'dtd' file is never exported on the Mac. While the MANIFEST file is listed in NGLayoutBuildList.pl, I forgot to check it in. We need to add xpfe/components/bookmarks/resources/locale/MANIFEST with the following lines: en-US:bm-props.dtd en-US:bookmarks.dtd

Thanks for fixing that, slamm. I think that this bug should be left open and the summary renamed to indicate that we should NOT crash if a DTD file isn't available. :^)

We no longer crash when a DTD is not present. nsChromeProtocolHandler::NewChannel was returning NS_OK even when Necko returned an error code. On fixing that, we no longer crash. This fix was checked in by Steve Dagley on the tip. We are not planning to check it into the branch.

listen closely. This bug is now fixed and VERIFIED for 1999082412-M9 builds AND for 1999082513-M10.