User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a4) Gecko/20040927 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a4) Gecko/20040927 . Reproducible: Always Steps to Reproduce: 1. Right click on about:config. 2. New -> String / Integer / Boolean. 3. A prompted box is shown, and the contextmenu doesn't disappear until the prompted box closed.

Confirmed using Mozilla 1.8a4 on Windows XP SP 1. No loss of function, just a cosmetic problem. Severity -> trivial.

Adding regression keyword since this works with 1.7.5. This bug also happens on Linux. Moving to Core/Event Handling (could be wrong...)

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

I'm not sure of all of the ramifications with doing what I suggest in this patch to popup.xml are so I am not asking for review. So far my tests have been favorable in that this works in this instance where the context menu only has one menupopup as well as when it has additional menupopup elements below that one and I have not found any side affects as of yet.

Note (sorry for the spam) - the function that is called by the menuitem uses nsIPromptService so it doesn't return immediately. I am pretty sure this is why the context menu continues to display. The odd thing is that it does not continue to display if the menuitem is a child of the root popup. I suspect that popupHide is called somewhere else for this instance and I will try to find the code that closes the popup when it is a child of the root. I suspect that this may be a toolkit widget bug and that there is code that only fixes this in the more likely scenario where the menuitem is a child of the root.

Testcase that demonstrates this behavior. I'm not sure if the patch in progress is the right way to go since I would expect the popup to not be destroyed when the function the menuitem calls doesn't immediately return yet the current behavior is for popuphiding on all menupopup parents and not for the first popup in the context menu.

This did regress between 2004-08-09 and 2004-08-10. Maybe a regression from fixing bug 230170?

Yes, this almost certainly regressed with bug 230170. There were tons of assumptions in the menu code about things always happening synchronously, and those assumptions are no longer correct. Does anyone know exactly which style change is involved here? Or rather, which attribute is being changed to take down the popup?

Not sure if this helps but it seems to disappear and then reappear... there is also bug 71219 that had essentially the same issue.

Hmmm... Probably the "_moz_menuactive" attribute is the issue here (there's actually style depending on that one). I suppose I could hack that restyle to be sync too, if we know it only applies to a limited set of content nodes... I wonder what today's equivalent of DestroyChain is.

I doubt this is any help but doing a Flush_Layout here instead of a Flush_OnlyReflow appears to fixe this issue. http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsPopupSetFrame.cpp#556

Right. Flush_Layout flushes out style reresolves.... but that's a good way to trigger crashes, when done from frame code.

Robert, are you actively working on this? Or should I try to sort it out?

bz - please do. I'm not familiar with this code and don't have the time right now to get up to speed.

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

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

This is the best I can do without rewriting menus to do all this from content instead of from frames (and to trigger the menu command off an event or something). It'll do for now, and maybe for 1.9 we can actually rewrite menus a tad....

Comment on attachment 183698 [details] [diff] [review] Wallpaper.... Requesting 1.8b2 approval -- this is a very safe wallpaper for some menu issues that we can't really address in the 1.8 timeframe...

Comment on attachment 183698 [details] [diff] [review] Wallpaper.... a=asa

Fixed

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

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