Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

New Embedding API Sample Code Crashes

2 views
Skip to first unread message

jerry...@gmail.com

unread,
Mar 24, 2009, 5:55:52 PM3/24/09
to
Sorry to belabor the point, but we're *still* stuck trying to access
the DOM in the new embedding API. I've put together what I believe to
be a complete, minimal-example in GTK/X11 that directly inserts the
example code from https://wiki.mozilla.org/Embedding/NewApi/XpcomAccess
into the DocumentLoaded callback (as suggested on that page).

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?

Boris Zbarsky

unread,
Mar 24, 2009, 9:09:05 PM3/24/09
to
jerry...@gmail.com wrote:
> 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));

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

jerry...@gmail.com

unread,
Mar 24, 2009, 10:18:39 PM3/24/09
to
On Mar 24, 6:09 pm, Boris Zbarsky <bzbar...@mit.edu> wrote:
>
> So htmlDoc is non-null, right?  When you say "dies" I assume you crash?
>

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

Boris Zbarsky

unread,
Mar 24, 2009, 10:26:48 PM3/24/09
to
jerry...@gmail.com wrote:
> 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.

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

jerry...@gmail.com

unread,
Mar 25, 2009, 4:30:41 AM3/25/09
to
On Mar 24, 7:26 pm, Boris Zbarsky <bzbar...@mit.edu> wrote:
>
> In gdb, "set print object on" and then see what it claims the mRawPtr to be.
>

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?

Boris Zbarsky

unread,
Mar 25, 2009, 11:38:15 AM3/25/09
to
jerry...@gmail.com wrote:
> It claims it's a nsISupports pointer.
...

> 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

Looks like you don't have symbols for your XULRunner. Getting those
would help with debugging a good bit...

-Boris

0 new messages