Last Comment Bug 238413 - element.builder.rebuild() crashes in builds 20040309 and later
: element.builder.rebuild() crashes in builds 20040309 and later
Status: NEW
: crash, testcase
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: x86 Windows XP
: -- critical (vote)
: ---
Assigned To: Christopher Aillon (sabbatical, not receiving bugmail)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-23 12:25 PST by HJ
Modified: 2012-04-07 15:20 PDT (History)
8 users (show)
asa: blocking1.7-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Dr Watson log (42.00 KB, text/plain)
2004-03-24 01:14 PST, Raj Bhaskar
no flags Details
xul text case (can only be loaded from chrome) (3.90 KB, text/plain)
2004-04-02 20:27 PST, HJ
no flags Details

Description HJ 2004-03-23 12:25:30 PST
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 !!!
Comment 1 HJ 2004-03-23 12:32:51 PST
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
Comment 2 Raj Bhaskar 2004-03-23 15:23:02 PST
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).
Comment 3 Raj Bhaskar 2004-03-24 01:14:08 PST
Created attachment 144643 [details]
Dr Watson log

In case it's any use, I've attached the Dr Watson stack dump.  As I said in
comment 2, Talkback was not part of my build, so I can't provide an ID
Comment 4 Raj Bhaskar 2004-03-25 07:33:27 PST
Someone from the MozillaZine forums reproduced the MultiZilla crash and reported
talkback ID TB4559G captured at: 3/24/2004 4:33 PM
Comment 5 HJ 2004-03-26 20:07:18 PST
Christopher, I'm reassigning this bug to you, because we think that it was your
patch that caused this crasher bug. Can you please fix this bug, or at least
backout the lines that caused this bug?
Comment 6 HJ 2004-03-30 08:39:29 PST
-> CrashWeek Effort
Comment 7 Neil Pryde 2004-03-30 08:40:35 PST
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."
Comment 8 HJ 2004-04-02 20:24:37 PST
mozilla 20040309 still crashes for me on WinXP. I will add a testcase that
generated a file called: "bug-238413.rdf" in your profile directory. The content
of that file looks like this:

<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:MZ="http://multizilla.mozdev.org/rdf#">
<RDF:Seq RDF:about="urn:useragent-data">
<RDF:li>Line one</RDF:li>
<RDF:li>Line two</RDF:li>
<RDF:li>Line three</RDF:li>
<RDF:li>Line four</RDF:li>
<RDF:li>Line five</RDF:li>
</RDF:Seq>
</RDF:RDF>

Loading the XUL file (from chrome) should display: "start, adding datasource,
rebuilding and done" but crashes in 20040308+ builds.
Comment 9 HJ 2004-04-02 20:27:25 PST
Created attachment 145360 [details]
xul text case (can only be loaded from chrome)
Comment 10 HJ 2004-04-02 20:31:24 PST
Christopher, anything else that we can do to help?
Comment 11 HJ 2004-04-05 02:55:40 PDT
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.
Comment 12 Jan Varga [:janv] 2004-04-05 04:33:21 PDT
From bug 236946:

Index: content/xul/content/src/nsXULElement.cpp
===================================================================
RCS file: /cvsroot/mozilla/content/xul/content/src/nsXULElement.cpp,v
retrieving revision 1.512
diff -p -u -d -8 -r1.512 nsXULElement.cpp
--- content/xul/content/src/nsXULElement.cpp	6 Mar 2004 00:22:02 -0000	1.512
+++ content/xul/content/src/nsXULElement.cpp	9 Mar 2004 21:18:18 -0000

// XXX hack because we can't use "mutable"
nsXULElement* unconstThis = NS_CONST_CAST(nsXULElement*, this);

nsCOMPtr<nsIXULTemplateBuilder> builder;

- return builder->CreateContents(NS_STATIC_CAST(nsIStyledContent*, unconstThis));
+ return builder->CreateContents(unconstThis);

from nsIXULTemplateBuilder.idl:
[ptr] native nsIContent_ptr(nsIContent);
[noscript] void createContents(in nsIContent_ptr aElement);
Is is safe to pass |uncostThis| there?
Comment 13 HJ 2004-04-05 17:25:49 PDT
Hmm, InsertElementAt() also fails in these builds but RemoveElementAt() still works.

note: GoogleBox now also crashes as a result of this bug :(
Comment 14 Christopher Aillon (sabbatical, not receiving bugmail) 2004-04-05 19:10:06 PDT
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.
Comment 15 HJ 2004-04-05 23:11:23 PDT
(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? 
Comment 16 Benjamin Smedberg [:bsmedberg] 2004-04-06 07:35:01 PDT
(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.
Comment 17 Asa Dotzler [:asa] 2004-04-28 14:55:03 PDT
Does this impact the SeaMonkey (or Firefox or Thunderbird) applications?
Comment 18 HJ 2004-12-07 01:56:10 PST
(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
Comment 19 Christopher Aillon (sabbatical, not receiving bugmail) 2005-01-10 14:48:33 PST
HJ, could you revert the part of the patch Jan mentioned in comment 12 and let
me know if that helps?
Comment 20 HJ 2005-01-11 06:44:59 PST
(In reply to comment #19)
> HJ, could you revert the part of the patch Jan mentioned in comment 12 and let
> me know if that helps?

No I can't, I wich I could. Also, it still crashes like before.
Comment 21 HJ 2005-01-11 06:47:03 PST
s/wich/wish

Note to self: open your eyes, for real, and have breakfast first, before adding
comments at 6:45AM ;)
Comment 22 HJ 2006-02-23 02:33:22 PST
Can someone please make that change so that I can test it?
Comment 23 Wayne Mery (:wsmwk, NI for questions) 2012-04-07 15:20:13 PDT
probably worth retesting. 
Note HJ's email address is dead.

Note You need to log in before you can comment on or make changes to this bug.