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

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

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.

Comment 1

[Martijn Wargers (dead)]

Attachment: popup needed for testcase

Comment 2

[Martijn Wargers (dead)]

Attachment: testcase

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

Comment 3

[Martijn Wargers (dead)]

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.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Bizarre testcase ;)

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The frame probably isn't in the frame tree so doesn't get Destroy()ed when the frame tree is torn down.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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....

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Small testcase for the asserts

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

181 drivers tried this and it didn't crash any of us, so is this perhaps trunk-only?

Comment 10

[Myk Melez [:myk] [@mykmelez]]

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".

Comment 11

[Boris Zbarsky [:bzbarsky]]

It's possible that this is trunk-only, yes.  Depends on where the IsValidSibling changes landed and are planned to land, probably.

Comment 12

[Boris Zbarsky [:bzbarsky]]

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.

Comment 13

[Daniel Veditz [:dveditz]]

Seems to be trunk-only, minusing for 1.8.0.7 -- please renominate if that turns out not to be the case.

Comment 14

[Bernd]

fixed by the checkin for bug bug 341858 

Comment 15

[Stephen Donner [:stephend] Not actively reading bugmail]

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.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Added crashtest: http://hg.mozilla.org/mozilla-central/rev/4d4e400e1301