Created attachment 268784 [details] testcase When clicking on the document of the testcase, Mozilla crashes. https://crash-reports.mozilla.com/reports/report/index/88bd6778-1d8c-11dc-99b8-001a4bd43ef6 0 nsPopupSetFrame::Destroy() 1 nsFrameList::DestroyFrames() 2 nsContainerFrame::Destroy() 3 nsBoxFrame::RemoveFrame(nsIAtom *,nsIFrame *) 4 nsRootBoxFrame::RemoveFrame(nsIAtom *,nsIFrame *) 5 nsFrameManager::RemoveFrame(nsIFrame *,nsIAtom *,nsIFrame *) 6 nsCSSFrameConstructor::ContentRemoved(nsIContent *,nsIContent *,int,int) 7 PresShell::ContentRemoved(nsIDocument *,nsIContent *,nsIContent *,int) 8 nsBindingManager::ContentRemoved(nsIDocument *,nsIContent *,nsIContent *,int) 9 nsNodeUtils::ContentRemoved(nsINode *,nsIContent *,int) It also crashes branch builds, so I'm marking it security sensitive for now. I guess this depends on the fix for bug 279703.
Created attachment 269144 [details] [diff] [review] Patch rev. 1 Return early in LaunchPopup() if the popup id refers to the popup itself. Tooltips are probably not affected (at least I couldn't find a testcase that triggered it) but I added a similar check to ShowTooltip() just in case.
I'm a bit worried that there is nsDocElementBoxFrame created for the popup, though what should be done in this case...
I think Enn is best placed to comment on this... I'm curious as to whether there's a way to avoid opening an open popup; might there be an exploit caused by having a popup be the context menu for a menuitem in a submenu of itself?
The patch in bug 279703 already adds a check for the XULPopupListener change, but the tooltip change looks OK too.
mozilla/content/xul/content/src/nsXULPopupListener.cpp 1.146 mozilla/layout/xul/base/src/nsPopupSetFrame.cpp 1.167 mozilla/layout/xul/base/src/nsXULTooltipListener.cpp 1.63 -> FIXED
This still affects the branch. Requesting blocking.
Verified fixed, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071905 Minefield/3.0a7pre
Comment on attachment 269144 [details] [diff] [review] Patch rev. 1 Low-risk crash fix.
Comment on attachment 269144 [details] [diff] [review] Patch rev. 1 approved for 126.96.36.199 and 188.8.131.52, a=dveditz for release-drivers
MOZILLA_1_8_BRANCH mozilla/content/xul/content/src/nsXULPopupListener.cpp 184.108.40.206 mozilla/layout/xul/base/src/nsPopupSetFrame.cpp 220.127.116.11 mozilla/layout/xul/base/src/nsXULTooltipListener.cpp 18.104.22.168 MOZILLA_1_8_0_BRANCH mozilla/content/xul/content/src/nsXULPopupListener.cpp 22.214.171.124 mozilla/layout/xul/base/src/nsPopupSetFrame.cpp 126.96.36.199.2.8 mozilla/layout/xul/base/src/nsXULTooltipListener.cpp 188.8.131.52
verified fixed 184.108.40.206 using the testcase from this bug and: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11pre) Gecko/2007090308 BonEcho/18.104.22.168pre and : Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:22.214.171.124pre) Gecko/20070903 BonEcho/126.96.36.199pre ID:2007090304 no crash on testcase - adding verified keyword
The test case doesn't crash the FF 188.8.131.52 release: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/20071210 Firefox/220.127.116.11pre.
I tried synthesizing the mouse click to automate the crash but have failed. Is there any trick to dispatch a mouse click to the popup that will cause the crash?
Created attachment 370631 [details] testcase This crashes automatically, without having to click in the document in builds without the patch that fixed this. In Firefox 3 and beyond there is now openPopup instead of showPopup, that's why the difference in code paths. I also tried to do a check on the state property of the popup, but that thing doesn't seem to work correctly at all in this case. https://developer.mozilla.org/en/XUL/menupopup#p-state
crash test added http://hg.mozilla.org/mozilla-central/rev/cbef28dd9944