Caillon asked me (http://bugzilla.mozilla.org/show_bug.cgi?id=236946#c7) to file
a new bug for this so I did.
I keep crashing with element.builder.rebuild() It still works in 20040308 but
fails in all builds with the patch for bug 236946 (cleanup in nsXULElement).
Here's a small code example:
<menu label="&qpHTTPUserAgentSettings.label;">
<menupopup id="UAgentMenu" datasources="rdf:null"
ref="urn:useragent-data"
onpopupshowing="initUserAgentMenu(this);">
<template>
<rule>
<menuitem uri="rdf:*" label="rdf:*" type="radio"/>
</rule>
</template>
</menupopup>
</menu>
function initUserAgentMenu(aParent)
{
aParent.builder.rebuild(); <= crash !!!

Steps to reprodue are:
1) install MultiZilla
2) click on QPrefs button
3) hover over 'Browser Spoofing'
Current result : crash
Expected result: no crash
I think this is caused by this change:
- return
builder->CreateContents(NS_STATIC_CAST(nsIStyledContent*, unconstThis));
+ return builder->CreateContents(unconstThis);
Raj, can you please add dr watson/talkback data if they need it, you probably
know that Neil and I can't (read are not allowed to do this kind of actions).
Thanks,
/HJ

Mozilla crashes silently on my WinXP build (2004-03-11-08-trunk) and although it
creates a Dr Watson log in my Win2K build (2004-03-21-08-trunk), I don't think
that Talkbalk was installed (as in, not an option, not that I chose not to
install it).

I just used HJ's bugzilla account because of this message:
" You tried to change the Severity field from major to critical, but only the
owner or submitter of the bug, or a sufficiently empowered user, may change that
field."

Jan, can you please have a look at this? This should really be fixed for mozilla
1.7 final. We really need this for work. We're stuck with old mozilla builds
now, because of a serious security issues in prior builds (not this bug). It
would be very nice if you could gear this up a bit, thanks.

It should be just as safe to pass nsXULElement* as it is to pass
nsIStyledContent* to a method which wants nsIContent* since both are unambiguous
descendants of nsIContent*. I really don't understand why that change would
cause this to break (if it really does).
HJ, a testcase that I can load from non-chrome would be a bigger help.

(In reply to comment #14)
> ... I really don't understand why that change would cause this to break (if it
really does).
Well, I can't find anything else in bonsai for this time time frame, do you?
> HJ, a testcase that I can load from non-chrome would be a bigger help.
Eh, and how should that work? I get a bunch of (security) errors when I try.
All you have to do is to add the attachment to your comm.jar and use
chrome://navigator/content/filename.xul You can simply remove it when you're
done testing. That should do the trick.
Btw, what about comment #4? Is that talkback data any good?

(In reply to comment #14)
> It should be just as safe to pass nsXULElement* as it is to pass
> nsIStyledContent* to a method which wants nsIContent* since both are unambiguous
> descendants of nsIContent*. I really don't understand why that change would
Well, that's theoretically true, but we frequently-enough key hashtables on
nsIContent*, and you would get a different pointer depending on how you do the cast.

(In reply to comment #17)
> Does this impact the SeaMonkey (or Firefox or Thunderbird) applications?
Yes and no. Yes, if you add extensions like MultiZilla,but there might be others
having the same kind of difficulties.
Asa, this is one of the issues that keeps us from having a MultiZilla version
for Mozilla Firefox, so yes, it would be nice if this could be fixed for Mozilla 1.8