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

Accessing the DOM in the new embedding API

2 views
Skip to first unread message

jerry...@gmail.com

unread,
Mar 10, 2009, 5:23:08 AM3/10/09
to
We've recently implemented a minimal embedding application using the
new (and wonderful!) embedding API (specifically, via GTK and X11).
In particular, we implement a MozViewListener and we've verified that
the DocumentLoaded callback is getting called at what appears to be
the right time.

However, the following implementation of DocumentLoaded always prints
"Number of elements is 0". This is still a great step forward from
the old API--in which several of these functions would barf on us and
return errors--but it's somewhat vexing nonetheless.

void WebListener::DocumentLoaded()
{
// myView is the MozView we're using to drive the embedding app
nsIDOMWindow2* dom_window=myView->GetDOMWindow();

nsresult rv;

nsCOMPtr<nsIDOMDocument> domDocument;
rv = dom_window->GetDocument(getter_AddRefs(domDocument));
if (NS_FAILED(rv)) printf("GetDOMDocument failed rv = %08X\n",
rv);

nsCOMPtr<nsIDOMNodeList> nodelist;
rv = domDocument->GetElementsByTagName(NS_LITERAL_STRING
("*"),getter_AddRefs(nodelist));
if (NS_FAILED(rv)) printf("GetElements by tag name failed %08X\n",
rv);

nsCOMPtr<nsIDOMDocumentView> domView = do_QueryInterface
(domDocument,&rv);
if(NS_FAILED(rv) || !domView) printf("domView failed %08X\n", rv);

nsCOMPtr<nsIDOMAbstractView> abstractView;
rv = domView->GetDefaultView(getter_AddRefs(abstractView));
if(NS_FAILED(rv) || !abstractView) printf("abstractView failed %08X
\n", rv);

nsCOMPtr<nsIDOMViewCSS> viewCSS;
viewCSS = do_QueryInterface(abstractView, &rv);
if(NS_FAILED(rv) || !viewCSS) printf("viewCSS failed %08X\n", rv);

PRUint32 numelements = 0;
rv = nodelist->GetLength(&numelements);
if (NS_FAILED(rv)) printf("GetLength failed %08X\n", rv);
printf("Number of elements is %d\n", numelements);
}

Can someone please help us figure out why this isn't working and (more
importantly) how to get at the DOM in the new embedding API?

Mark Finkle

unread,
Mar 15, 2009, 1:33:03 AM3/15/09
to
On Mar 10, 5:23 am, jerrytal...@gmail.com wrote:
...

> Can someone please help us figure out why this isn't working and (more
> importantly) how to get at the DOM in the new embedding API?

Here is a different example of accessing the DOM:
https://wiki.mozilla.org/Embedding/NewApi/XpcomAccess

jerry...@gmail.com

unread,
Mar 15, 2009, 10:52:12 PM3/15/09
to
On Mar 14, 10:33 pm, Mark Finkle <mark.fin...@gmail.com> wrote:
>
> Here is a different example of accessing the DOM:https://wiki.mozilla.org/Embedding/NewApi/XpcomAccess
>

Yeah, I saw this example before, but the nsIDOMDocument returned by
the interface (as in that example) is precisely the same as the one
returned via myView->GetDOMWindow()->GetDocument(). Is the
DocumentLoaded callback the wrong place to inspect the DOM and layout?

mlutken

unread,
Mar 16, 2009, 5:35:55 AM3/16/09
to
I am not using the new embedding API, but something I made myself and
I just tried out your example - using Firefox 3.06 code.
I can say that it works perfectly for me, so it's probably not at
problem with the nsI* classes. It's more likely that
the page is not actually fully loaded when you think it is or some bug
in the new embedding API.

I am not sure how much this helps though. I could send you my code,
but it's not based on the new Embedding API, but on my own and I
mainly use wxWidgets allthough I have prepared for Gtk+ also.

-Martin Lutken

jerry...@gmail.com

unread,
Mar 23, 2009, 6:52:48 PM3/23/09
to
On Mar 16, 2:35 am, mlutken <nit...@lutken.dk> wrote:
>
> I am not using the new embedding API, but something I made myself and
> I just tried out your example - using Firefox 3.06 code.
> I can say that it works perfectly for me, so it's probably not at
> problem with the nsI* classes. It's more likely that
> the page is not actually fully loaded when you think it is or some bug
> in the new embedding API.
>

This is what we suspect as well: however, it's fairly clear that the
page *ought* to be loaded by the time the DocumentLoaded callback is
triggered. Can anyone who's more familiar with the guts of the new
API proffer an opinion?

0 new messages