The code is available at http://pastebin.com/m694ad30e. On my system,
it dies on line 46:
doc->CreateElement(NS_LITERAL_STRING("div"), getter_AddRefs(newdiv));
When we replace the contents of the DocumentLoaded callback with the
code we actually want to run, we find ourselves with similar problems.
Are we not setting something up properly? If we *are* setting
everything up properly, is the DocumentLoaded callback the right place
for our DOM inspection code to go?
So htmlDoc is non-null, right? When you say "dies" I assume you crash?
What's the value of |doc| at this point? Is it pointing to a valid
nsDocument object? Or do you not have a debug Gecko (or at least one
with symbols) to work with here?
-Boris
Yes, htmlDoc is not null (see the "if" statement on line 40). Yes, I
do indeed mean crash.
> What's the value of |doc| at this point? Is it pointing to a valid
> nsDocument object? Or do you not have a debug Gecko (or at least one
> with symbols) to work with here?
In the debugger, the mRawPtr for doc is not garbage: I'm not entirely
sure how to poke around more. I'm using xulrunner-1.9-dev on Ubuntu
8.10.
When we drop the code that we *actually* want to run into the
DocumentLoaded callback, nothing crashes, but GetElementsByTagName
always returns a node list with 0 elements (see
http://groups.google.com/group/mozilla.dev.embedding/browse_thread/thread/b9246695da9a2f94/655796336aeaf6c9?lnk=raot#655796336aeaf6c9).
In gdb, "set print object on" and then see what it claims the mRawPtr to be.
Does the crash happen at this call, or somewhere inside CreateElement?
> When we drop the code that we *actually* want to run into the
> DocumentLoaded callback, nothing crashes, but GetElementsByTagName
> always returns a node list with 0 elements (see
> http://groups.google.com/group/mozilla.dev.embedding/browse_thread/thread/b9246695da9a2f94/655796336aeaf6c9?lnk=raot#655796336aeaf6c9).
Right. For what it's worth, looking at where DocumentLoaded is called,
it really should be equivalent to the JS onload event.
-Boris
It claims it's a nsISupports pointer.
> Does the crash happen at this call, or somewhere inside CreateElement?
All I can see in the backtrace is:
#0 0x00007f85cf0d0015 in raise () from /lib/libc.so.6
#1 0x00007f85cf0d1b83 in abort () from /lib/libc.so.6
#2 0x00007f85cf1110c8 in ?? () from /lib/libc.so.6
#3 0x00007f85cf116a58 in ?? () from /lib/libc.so.6
#4 0x00007f85cf1190a6 in free () from /lib/libc.so.6
#5 0x00007f85ca0b60e2 in ?? () from /usr/lib/xulrunner-1.9.0.7/
libxul.so
#6 0x00000000004021fe in WebListener::DocumentLoaded (this=0x24214e0)
at src/Test.cpp:46
#7 0x00007f85d21dc9f0 in WebBrowserChrome::OnStateChange
(this=0x2301d80, aStateFlags=131088) at ../../common/
WebBrowserChrome.cpp:191
...
>
> Right. For what it's worth, looking at where DocumentLoaded is called,
> it really should be equivalent to the JS onload event.
>
Right. This is what's confusing the #&%* out of me: things are
clearly hooked up correctly enough for the page to display and this
callback to fire at the right place, but the DOM information just
doesn't seem to be there.
Out of curiosity, does my little sample app work correctly for anyone
else? I mean, it really *should* be the most minimal GTK example that
hits the DOM, right?
Looks like you don't have symbols for your XULRunner. Getting those
would help with debugging a good bit...
-Boris