Crash [@ nsComboboxControlFrame::HandleRedisplayTextEvent] with testcase that closes window during rendering




12 years ago
7 years ago


(Reporter: Martijn Wargers (dead), Assigned: smaug)


({crash, regression, testcase})

Windows XP
crash, regression, testcase
Dependency tree / graph
Bug Flags:
blocking1.8.1 -
blocking1.8.0.7 -
in-testsuite +

Firefox Tracking Flags

(Not tracked)


(crash signature)


(3 attachments)



12 years ago
See upcoming testcase that crash current Mozilla builds.

Talkback ID: TB21904776Y
nsComboboxControlFrame::HandleRedisplayTextEvent   NS_ProcessNextEvent_P   nsBaseAppShell::Run   0x00393de4

The testcase opens a popup window that closes very quickly again after opening.
The popup window contains certain html tags that cause the crash.

Comment 1

12 years ago
Created attachment 232756 [details]
popup needed for testcase

Comment 2

12 years ago
Created attachment 232758 [details]

When clicking on the button, you need to get a new window, the window should not open in a new tab.

Comment 3

12 years ago
This seems like a regression.
It doesn't crash with a 2006-05-28 build, it crashes with a 2006-05-29 build:
So I guess a regression from bug 338897.
Although this doesn't crash on the latest branch builds.
Blocks: 338897
Keywords: regression

Comment 4

12 years ago
Bizarre testcase ;)
Assignee: nobody → Olli.Pettay

Comment 5

12 years ago
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....
Flags: blocking1.9?
Flags: blocking1.8.1?
Flags: blocking1.8.0.7?
Created attachment 233504 [details]
Small testcase for the asserts
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 -- please renominate if that turns out not to be the case.
Flags: blocking1.8.0.7? → blocking1.8.0.7-

Comment 14

11 years ago
fixed by the checkin for bug bug 341858 
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:; no crash.
Flags: blocking1.9? → in-testsuite?
Crash Signature: [@ nsComboboxControlFrame::HandleRedisplayTextEvent]
You need to log in before you can comment on or make changes to this bug.