See upcoming testcase that crash current Mozilla builds. Talkback ID: TB21904776Y nsComboboxControlFrame::HandleRedisplayTextEvent NS_ProcessNextEvent_P nsBaseAppShell::Run 0x00393de4 0xccccc3c0 The testcase opens a popup window that closes very quickly again after opening. The popup window contains certain html tags that cause the crash.
Created attachment 232758 [details] testcase When clicking on the button, you need to get a new window, the window should not open in a new tab.
This seems like a regression. It doesn't crash with a 2006-05-28 build, it crashes with a 2006-05-29 build: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-28+05&maxdate=2006-05-29+12&cvsroot=%2Fcvsroot So I guess a regression from bug 338897. Although this doesn't crash on the latest branch builds.
Bizarre testcase ;)
Assignee: nobody → Olli.Pettay
This happens because nsComboboxControlFrame::Destroy() isn't called. Does anyone know why/how that might happen. Easy fix for this crash is to use nsWeakFrame in RedisplayTextEvent, but I'd like to understand why ::Destroy isn't called.
The frame probably isn't in the frame tree so doesn't get Destroy()ed when the frame tree is torn down.
The problem is at IsValidSibling returns true here, but we don't actually construct a table caption frame for the <select>. Then when we try to insert it into the outer table it bails out (and asserts). We should either fix IsValidSibling somehow to handle special content (not sure how, since we need to do that after XBL resolution, which happens much later right now) or we shouldn't trust the return value of IsValidSibling for purposes of determining the parent frame....
12 years ago
Depends on: 341858
181 drivers tried this and it didn't crash any of us, so is this perhaps trunk-only?
Flags: blocking1.8.1? → blocking1.8.1-
Note: I tested on recent trunk and branch builds with my "New pages should be opened in:" preference set to both "a new window" and "a new tab". The only time it crashed was on the trunk build with the preference set to "a new window".
It's possible that this is trunk-only, yes. Depends on where the IsValidSibling changes landed and are planned to land, probably.
And for what it's worth, the way to test for this bug is to check for the asserts, not for the crash. The crash on that exact testcase may depend on exact UI timing, but any build that shows the asserts is crashable. Just toss in some animated images.
Seems to be trunk-only, minusing for 22.214.171.124 -- please renominate if that turns out not to be the case.
Flags: blocking126.96.36.199? → blocking188.8.131.52-
fixed by the checkin for bug bug 341858
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Verified FIXED with build 2006-11-17-08 of SeaMonkey trunk under Windows XP with the testcase at: https://bugzilla.mozilla.org/attachment.cgi?id=232758&action=view; no crash.
Status: RESOLVED → VERIFIED
11 years ago
Flags: blocking1.9? → in-testsuite?
Added crashtest: http://hg.mozilla.org/mozilla-central/rev/4d4e400e1301
Flags: in-testsuite? → in-testsuite+
Crash Signature: [@ nsComboboxControlFrame::HandleRedisplayTextEvent]
You need to log in before you can comment on or make changes to this bug.