Using build 2001042208 on Win2K Steps to Reproduce: 1. Right click on a Personal Toolbar item and select "Rename". 2. While the item name is editable, right click on it. Result: Crash Reproducible: Always The same thing happens with "New Folder"

I see this in a Linux 2001-04-22 CVS build as well: #0 0x41a00156 in nsPopupSetFrame::MarkAsGenerated (this=0x8ab4528, aPopupContent=0x89a95c8) at nsPopupSetFrame.cpp:517 #1 0x419fff7b in nsPopupSetFrame::CreatePopup (this=0x8ab4528, aElementContent=0x89a85d0, aPopupContent=0x89a95c8, aXPos=293, aYPos=92, aPopupType=@0xbfffcd5c, anAnchorAlignment=@0xbfffcdf4, aPopupAlignment=@0xbfffce8c) at nsPopupSetFrame.cpp:469 #2 0x419c2cac in nsPopupSetBoxObject::CreatePopup (this=0x89aa418, aSrcContent=0x89a85d4, aPopupContent=0x89a95cc, aXPos=293, aYPos=92, aPopupType=0xbfffd388, anAnchorAlignment=0xbfffd234, aPopupAlignment=0xbfffd14c) at nsPopupSetBoxObject.cpp:139 (gdb) frame 0 #0 0x41a00156 in nsPopupSetFrame::MarkAsGenerated (this=0x8ab4528, aPopupContent=0x89a95c8) at nsPopupSetFrame.cpp:517 517 mContent->ChildCount(childCount); (gdb) p mContent $1 = (nsIContent *) 0x0

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

nav triage team: marking p1, mozilla0.9.1, nsbeta1+ and reassigning to mcafee since ben is pretty bogged down for 0.9.1

The bookmarks case is easily reproduceable on linux. I think somebody's trying to post a tooltip for this scenario, and we're colliding with the selection. Over to pinkerton for a look. An obvious null pointer to start, but fixing that didn't help much.

toolkit crash, toolkit gets to triage.

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

ok, i guess this is 0.9.1

here's what's going on: rightclicking on the edit field causes the onCreate method to be fired from the contextMenu's popupSetFrame. this goes down through js and causes someone to call nsXULElement::Focus(). The blur event that comes from this focus again goes through js and (i'm assuming) into the inline-edit code which probably watches for blur (i can't find it in the tree). This blur ends up calling nsXULElement::RemoveChild() which destroys the frame and all it's children. One of these children is the context menu's popupSetFrame. So once we come back from handling the onCreate event, the frame has been destroyed and life after that is a crap shoot: boom! What I don't understand is this: - why is the focus changing from js on the right click? - what node is being removed from the inline edit code that is causing the popupset to go away. ben? any comments here? where is the inline edit code?

ok, i attached a patch to prevent it from crashing, but it's only a sanity check that should be there anyway. We really need to get to the bottom of why the RemoveChild is deleting everything under the sun. If you apply the patch and try the steps to repro, you'll get an assert as the popup listener for the textarea goes away that it doesn't have a xul document. That seems bad and indicates more is wrong here than meets the eye. But it doesn't crash! ;)

ben and i have been investigating this. it seems to be a side-effect of the text widget changing focus and tweaking the change handler of the inline-edit field, causing it to go away out from under itself. ben is chasing this down.

The model of focus shifting here is very complex, and this is going to take some thought. 2 days.

adding nsbeta1+. Also Pink: if your fix is safe, shd we just get that in for m0.9.1 and figure out the real fix in m0.9.2?

Alternative Fix: Disable inline editing everywhere (not just in bookmarks manager, see bug 81767) Make edit operations spawn dialogs for user input. Figure out inline-editing in 6.(n+1)/Mozilla 1.0. 0.5-1 day.

please decide to do one solution soon.

Going for latter solution as it gives me the ability to work on other bugs. Patch in a few minutes... Yes, it's sad to lose this functionality but there were problems and would rather ship less slick but more functional, stable UI.

This patch also fixes 81767 (disable inline edit in bookmarks manager) and tidies up after my 35835 checkin. Inline edit code in bookmarks manager/toolbar has been either commented out or disabled. A dialog is now shown for new folder creation, and the properties dialog is launched for rename operations. This is not meant to be a long term solution, but one which will last through the rewrite of the bookmarks manager to use outliner (mid-term) and modifications of the toolbar to do inline editing properly (also, mid-term).

looks ok to me, r=pchen

Inline Edit has been disabled for all bookmarks access points. Fixed.

VERIFIED Fixed with 2001053108 builds on all platforms