User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060130 Firefox/1.6a1 Deer Park Alpha (latest nightly) crashes on the following: Reproducible: Always Steps to Reproduce: 1. Take a select box with fixed width. 2. remove a <option>-element with Javascript code: el.options[i] = null; 3. click there, where the item was. Actual Results: Deer Park crashes. Expected Results: It should mark the Javascript as invalid? Or interprete it correctly? For me this looks like a null-Pointer-exception :)

TB14585699K TB14585681G

If you don't want to open the url, here's the same as an attachment.

No crash in 1.9a1_2005110413, crash in 1.9a1_2005110422.

20060131: still crashing.

I guess this could be a regression from bug 314879.

(In reply to comment #5) > I guess this could be a regression from bug 314879. Couldn't find the crash()-call in the patch :-) ... It shouldn't be possible that javascript influences the application so hard. Shouldn't there be a try-catch around the whole thing? Anyway, you don't have to click on a certain point in the select box. I guess the size & width has something to do with this bug. Thanks for debugging!

Hey, if you want my stack, I posted thousands of them. but I don't know how to get the IDs back. Just search your database for my email address.

Johannes, only priveleged people can search by e-mail address. Just go to Program Files\Mozilla Firefox\extensions\talkback@mozilla.org\ and open up talkback.exe and paste a few IDs here.

Please stop spamming the bug. Please! I know exactly what the issue is; I'll have a patch soon. At least if I don't have to keep stopping to delete the bugmail... ;)

I get a couple of assertions, I've added the backtrace for the first assertion: ###!!! ASSERTION: Item was successful, but node from collection was null!: 'node ', file c:/mozilla/mozilla/layout/forms/nsListControlFrame.cpp, line 1594 Break: at file c:/mozilla/mozilla/layout/forms/nsListControlFrame.cpp, line 1594 And I've added the backtrace for the crash itself: Program received signal SIGSEGV, Segmentation fault. 0x04fdfe64 in nsListControlFrame::PaintFocus(nsIRenderingContext&, nsPoint) ( this=0x1040f930, aRC=@0x103d6798, aPt=0x22de94) at c:/mozilla/mozilla/layout/forms/nsListControlFrame.cpp:476 warning: Source file is more recent than executable. #0 0x04fdfe64 in nsListControlFrame::PaintFocus(nsIRenderingContext&, nsPoint) (this=0x1040f930, aRC=@0x103d6798, aPt=0x22de94) at c:/mozilla/mozilla/layout/forms/nsListControlFrame.cpp:476 #1 0x04fe9151 in PaintListFocus(nsIFrame*, nsIRenderingContext*, nsRect const&, nsPoint) (aFrame=0x1040fa0c, aCtx=0x103d6798, aDirtyRect=@0x22df44, aPt=@0x22ded4) at c:/mozilla/mozilla/layout/forms/nsSelectsAreaFrame.cpp:176 #2 0x0554a283 in nsDisplayGeneric::Paint(nsDisplayListBuilder*, nsIRenderingCon text*, nsRect const&) (this=0x1041246c, aBuilder=0x22e084, aCtx=0x103d6798, aDirtyRect=@0x22df44) at c:/mozilla/mozilla/layout/base/nsDisplayList.h:690 #3 0x04ed16ef in nsDisplayList::Paint(nsDisplayListBuilder*, nsIRenderingContex t*, nsRect const&) const (this=0x10412488, aBuilder=0x22e084, aCtx=0x103d6798, aDirtyRect=@0x22df44) at c:/mozilla/mozilla/layout/base/nsDisplayList.cpp:161 etc.

(In reply to comment #8) > Johannes, only priveleged people can search by e-mail address. Why aren't you privileged? > Just go to > Program Files\Mozilla Firefox\extensions\talkback@mozilla.org\ plus "components" > and open up > talkback.exe and paste a few IDs here. Here you are: http://talkback-public.mozilla.org/ says, the IDs are too high, don't know why... TB14588245H <-- TB14588545Q TB14588698H TB14595220W

David, Mats, there are three parts here: 1) End of hunk 1 -- actually fix the crash by null-checking something that can be null, at least in theory. 2) Hunk 2 -- Fix assertions (and make us not hit the case fixed in item 1) by adjusting our selected indices when options are removed. 3) Start of hunk 1 -- don't use textframes for sizing of the focus rect.

Comment on attachment 210269 [details] [diff] [review] Fix sr=dbaron. I *think* the focusedIndex != kNothingSelected test that you're removing is just an optimization, but I haven't taken the time to convince myself of that.

This bug is currently not reproducible due to bug 333817 (which means empty <select>s can't be focused). But I bet once that's fixed this problem will be back. ;)

Fixed.

Verified FIXED using the testcase: https://bugzilla.mozilla.org/attachment.cgi?id=210231 with SeaMonkey trunk build 2006-04-20-08on Windows XP; no crash.