294183 - crash when run with a menu build from a template [@ nsMenuPopupFrame::Notify]

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[x11]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

i'm tring to develop some apps using firefox and XUL, but when i test my app, it
crashed. please check the attachment, thx.

Reproducible: Always

Steps to Reproduce:
1.open the attached file "main4bug.xul" in firefox/mozilla
2.click menu "menu0"
3.select submenu "menu5"
4.select submenu "menu6"
5.repeat steps 1-4, firefox will crash or render this menu wrong

Actual Results:  
firefox will crash or render this menu wrong
but it runs very well with a menu not build from template(see test1.xul)

Expected Results:  
render the menu in right way all the time

i tried the demo under linux and windows xp, with firefox and mozilla, all them
crashed.

Comment 1

[x11]

Attachment: the xul can crash firefox

Comment 2

[x11]

Attachment: the rdf file used to build the menu in main4bug.xul

Comment 3

[x11]

Attachment: a xul with same menu but is not build with template

Comment 4

[Hermann Schwab]

confirming crash on Firefox 1.0.4,
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050509 Firefox/1.0+
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050514

Talkback:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB5846329E
Stack Trace  	
nsMenuPopupFrame::Notify 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/layout/xul/base/src/nsMenuPopupFrame.cpp,
line 2135]
nsTimerImpl::Fire 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/xpcom/threads/nsTimerImpl.cpp,
line 395]
PL_HandleEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/xpcom/threads/plevent.c,
line 674]
0x778b0c24


testcase doesn´t work from link, you need to download 1st attachment as
main4bug.xul and 2nd attachment as menu4bug.rdf and then load main4bug.xul

using the branch build, I couldn´t repeat steps 2 through 4 without reloading,
and crashed once.
using trunk builds, menus open just by hovering, no need to reload.
After some time the last entry, item06 had scroll arrows above and below.
I had to reload to get rid of them.

Comment 5

[x11]

Attachment: testcase2

Comment 6

[Boris Zbarsky [:bzbarsky]]

So is this a problem on trunk?

Comment 7

[Hermann Schwab]

Trunk crashing with testcase 2:
https://bugzilla.mozilla.org/attachment.cgi?id=183728
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050724 Firefox/1.0+
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050723 SeaMonkey/1.0a
TB7842586Q
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB7842586Q

Firefox1.06 didn't crash, Deerpark crashed but Talkback didn't come up.
 

Comment 8

[Hermann Schwab]

Talkback from Deerpark: TB7842961E

I've got Deerpark Alpha 2 installed from exe, and zip nightlys in other
directories. I'm using the same profile, and that gave some confusion since
Talkback was installed as Extension, Talkback was taken from the wrong directory.
There was a checkin lately, now that problem seems to be solved that Talkback
wouldn't be taken from the wrong directory, but also not from the correct one.

Comment 9

[Hermann Schwab]

same on Seamonkey and Deerpark
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB7842586Q
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB7842961E

PresShell::HandleDOMEventWithTarget 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6445]
nsMenuFrame::Execute 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsMenuFrame.cpp,
line 1624]
nsMenuFrame::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/xul/base/src/nsMenuFrame.cpp,
line 453]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6413]
PresShell::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6193]
nsViewManager::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp,
line 2503]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp,
line 2230]
HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/view/src/nsView.cpp, line
174]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1171]
nsWindow::DispatchMouseEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5794]
ChildWindow::DispatchMouseEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 6040]
nsWindow::WindowProc 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1348]
KERNEL32.DLL + 0x363b (0xbff7363b)
KERNEL32.DLL + 0x242e7 (0xbff942e7)
0x00ce86b6

Comment 10

[Hermann Schwab]

regressed between BuildID 2005051905 and BuildID 2005051923
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050519 Mnenhy/0.7

maybe regression isn't the right word, as it wasn't working correctly before.
But the crash was introduced somewhere inbetween there.

Steps to repeat:
1. Load attachment 183728 [details] (testcase 2), 
2. Open menu0 > menu5 > menu6 > item04
3. click on item04, instant crash.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-05-19+03%3A00&maxdate=2005-05-19+23%3A00&cvsroot=%2Fcvsroot

Comment 11

[Boris Zbarsky [:bzbarsky]]

Sounds like a "regression" from bug 262031 (in quotes because it's broken on
branch too).  I'm really not sure offhand what we can do here, short of fixing
bug 279703 maybe...

Comment 12

[[e-mail]]

Yes, this is bug 262031 again. I managed to get suite to crash with
nsXULElement::UnsetAttr on the stack which is a bit of a giveaway.
If you like, I could spiun up a patch to make SetCurrentMenuItem null-check
mCurrentMenu after calling SelectMenu which reduces the crashiness a little.

Comment 13

[Boris Zbarsky [:bzbarsky]]

If it's easy and helps a lot, sure.

Comment 14

[[e-mail]]

Attachment: Wallpaper

Comment 15

[[e-mail]]

Comment on attachment 190979 [details] [diff] [review]
Wallpaper

crash fix

Comment 16

[[e-mail]]

Wallpaper checked in, so fewer crashes, although not properly fixed as such...

Comment 17

[Martijn Wargers (dead)]

I still crash with testcase2, and with the mentioned steps in comment 10.
It looks like the wallpaper patch didn't really help.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

No crashes here with either testcase now that the popup rewrite has landed. FIXED?

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Though I'm also not able to see menu6 anymore when I expand menu5...

Comment 20

[Boris Zbarsky [:bzbarsky]]

Please file that regression as a separate bug, make sure enn is cced, etc.  And request blocking-1.9.

Comment 21

[Neil Deakin]

No crashing anymore