1.21 KB, application/vnd.mozilla.xul+xml
8.55 KB, text/plain
4.57 KB, patch
|Details | Diff | Splinter Review|
Created attachment 320623 [details] testcase (crashes Firefox when loaded) Loading the testcase makes Mac trunk debug Firefox crash [@ nsListBoxBodyFrame::OnContentRemoved]. mContent and mRowCount are both 0xdddddddd, so I'm guessing |this| is a deleted nsListBoxBodyFrame.
We're ending up with an nsListBoxObject that somehow holds a pointer to a dead mListBoxBody. At a guess, we have multiple nsListBoxObjects for the same node. Or something. Because nsListBoxBodyFrame::Destroy notifies about itself going away...
Can't reproduce on Linux. Error console shows: Security Error: Content at https://bugzilla.mozilla.org/attachment.cgi?id=320623 may not load data from data:text/xml,....
There is a pref that enables data urls for xbl, see discussion in bug 379644. I don't know the pref's name.
Sorry, I forgot to mention that you have to set layout.debug.enable_data_xbl to true for the testcase to "work". (See bug 379959.)
So we have nsListBoxObjects for two different <listbox>es, but one of them seems to find the listboxbody of the other one. Should FindBodyContent bail out if it runs into a listbox? roc, you know this code, right?
I don't, really.
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
Created attachment 334304 [details] [diff] [review] ensure that only one box object is bound to listboxbodyframe IMO this is enough. Just ensure that there is one-to-one mapping between boxobject and frame. If someone creates strange XUL where there are several listbox elements but only one listboxbody, the first created listboxobject gets access to the frame - sort of random, but we can't support that kind of XUL structure anyway. So better to prevent the crash.
Comment on attachment 334304 [details] [diff] [review] ensure that only one box object is bound to listboxbodyframe Can we check GetType() too, just to be safe? Just static-casting interface pointers like that worries me.
Well, if would be very strange if any other frame implemented nsIListBoxObject. The whole setup is a bit strange; nsListBoxObject implements nsIListBoxObject and so does nsListBoxBodyFrame. The idea is just that nsListBoxObject can forward most of the method calls easily to nsListBoxBodyFrame.
Pushed the patch
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Comment on attachment 334304 [details] [diff] [review] ensure that only one box object is bound to listboxbodyframe Is this too late for 18.104.22.168?
Attachment #334304 - Flags: approval22.214.171.124?
The testcase WFM on 1.8.
Comment on attachment 334304 [details] [diff] [review] ensure that only one box object is bound to listboxbodyframe Technically not too late, but I'd rather get this in 126.96.36.199 so it has more time to bake. We should also get a crash test for this landed after it lands on the branch.
Attachment #334304 - Flags: approval188.8.131.52? → approval184.108.40.206?
Comment on attachment 334304 [details] [diff] [review] ensure that only one box object is bound to listboxbodyframe Approved for 220.127.116.11, a=dveditz for release-drivers
Attachment #334304 - Flags: approval18.104.22.168? → approval22.214.171.124+
This is still reproducing in the current 126.96.36.199 build (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:188.8.131.52pre) Gecko/2008102304 GranParadiso/3.0.4pre). Did this actually get checked in?
Checked in 2008-10-23 10:10, do you have the right build?
No, probably not. :-) I *assumed* that it had been checked in during September so I didn't even check. I'll check with tomorrow's daily. Thanks!
Verified for 184.108.40.206 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:220.127.116.11pre) Gecko/2008102704 GranParadiso/3.0.4pre. Verified for trunk with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081026 Minefield/3.1b2pre.
Status: RESOLVED → VERIFIED
Keywords: fixed18.104.22.168 → verified22.214.171.124
This test uses data: URLs for XBL bindings, so I think it can't be added to the crashtest suite as-is.
It could be added to mochitest, right? Or heck, it could use relative URLs for the bindings... would that not work in reftest?
Crash Signature: [@ nsListBoxBodyFrame::OnContentRemoved]
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.