How to get the primaryshell/widget from nsIDocument* with Gecko SDK 2.0

[Madhu Tadiparthi]

Hi,
I do have native C++ code to interact with the document. The code simply
tries to get the widget of the document type nsIDocument*. Here the document
reference is correct as it is properly giving url/title values say for
google page. This code is working find for Gecko SDK 1.9.2. Now I am trying
to make it work for Gecko SDK 2.0 and I have seen that getPrimaryShell() is
no more supported in the SDK 2.0 and I used getShell() instead but it is
returning NULL pointer. Could any one help me how to over come this problem
by properly getting the widget of the document. Here is the sample code I
used. This is blocking me to proceed further. Please let me know if any
thing I am doing wrong here and is there any better way to get the widget.

nsIWidget* CNSHtmlDocument::getWidget(nsIDOMHTMLDocument* m_htmlDocument)
{
nsCOMPtr<nsIWidget> widget_moz19 = 0;
nsIDocumentPtr docPtr =
NSQIUtils::doQI_nsIDocument(do_QueryInterface(m_htmlDocument));
nsCOMPtr<nsIPresShell> presShell;

#ifdef FFDOMAIN_MOZ20
presShell = docPtr->GetShell(); //Not sure this is valid method to use or
not
#else
presShell = docPtr->GetPrimaryShell();
#endif
nsIViewManager* vm = 0;
if(presShell !=0)
vm = presShell->GetViewManager();
if (vm)
{
vm->GetRootWidget(getter_AddRefs(widget_moz19));
}
return widget_moz19;
}

Thanks in advance
Madhu Tadiparthi

[Boris Zbarsky]

Post by Madhu Tadiparthi
Now I am trying
to make it work for Gecko SDK 2.0 and I have seen that getPrimaryShell() is
no more supported in the SDK 2.0 and I used getShell() instead but it is
returning NULL pointer.

That means the document has no presshell at the point when you make the
call. This is a perfectly normal condition for a document to be in.

-Boris

[mads]

Post by Boris Zbarsky

Post by Madhu Tadiparthi
Now I am trying
to make it work for Gecko SDK 2.0 and I have seen that getPrimaryShell() is
no more supported in the SDK 2.0 and I used getShell() instead but it is
returning NULL pointer.

That means the document has no presshell at the point when you make the
call.  This is a perfectly normal condition for a document to be in.
-Boris

Thanks Boris for the immediate response. Could you tell me any way to
get the valid widget of that document in this scenario?
-Madhu Tadiparthi

[Boris Zbarsky]

Post by mads
Thanks Boris for the immediate response. Could you tell me any way to
get the valid widget of that document in this scenario?

If it doesn't have a presshell, it also doesn't have a widget. It's
just not being shown at all.

-Boris

[K.V]

Iam also facing smae issue, how can I get bounds of Document in
Firefox 4.0 using XPCOM APIs?

Post by mads
Thanks Boris for the immediate response. Could you tell me any way to
get the valid widget of that document in this scenario?

If it doesn't have a presshell, it also doesn't have a widget.  It's
just not being shown at all.
-Boris

[Boris Zbarsky]

Post by K.V
Iam also facing smae issue, how can I get bounds of Document in
Firefox 4.0 using XPCOM APIs?

Defined how? Do you want the size of the initial containing block size
for the document or the overflow area of the root scroll frame (if any)?

(Note that neither is available via "XPCOM" APIs, last I checked; you
need to examine internal objects for them.)

-Boris

[K.V]

Thanks for the quick reply.
I wrote an extension for Firefox, there I need to interact with the
controls. For that I tried to get the dimensions of the controls. I
used getWidget() on the nsIDocument* as mentioned in the sample code
to get the Screen Offset values (using WidgetToScreenOffset()). This
worked properly till Firefox3.6 version but not with Firefox 4.0
version.

I am looking to find the document Screen offset dimensions (for
visible block), which I can use to find the bounds of the internal
controls.

-KV

[Boris Zbarsky]

Post by K.V
I wrote an extension for Firefox, there I need to interact with the
controls. For that I tried to get the dimensions of the controls. I
used getWidget() on the nsIDocument* as mentioned in the sample code
to get the Screen Offset values (using WidgetToScreenOffset()). This
worked properly till Firefox3.6 version but not with Firefox 4.0
version.

Right, because content documents no longer have widgets. They might
also not be on the screen at all, for that matter, or be on it in
multiple places at once.

I can't tell you what the right approach is for you without having a
better idea of what you're actually trying to do, unfortunately....

-Boris