nsIWindowWatcher->GetChromeForWindow returns null

RESOLVED INCOMPLETE

Status

()

Core
Embedding: APIs
--
major
RESOLVED INCOMPLETE
14 years ago
a year ago

People

(Reporter: mihail, Assigned: Adam Lock)

Tracking

({testcase})

Trunk
x86
Windows XP
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

I'm writing an XPCOM component for the Windows version of mozilla. I need to 
find the HWND of the browser window, so I try to retreive the webbrowser 
chrome for the DOM document window, but nsIWindowWatcher->GetChromeForWindow 
returns a null nsIWebBrowserChrome pointer. It seems that Mozilla doesn't 
register a chrome for the DOM window. Here is a part of my source code:
 
nsCOMPtr<nsISimpleEnumerator> winenumerator;
PRBool bMoreElements;
// pInstance points to a class that has as a member a valid pointer to the 
nsIWindowWatcher service
rv = pInstance->windowwatcher->GetWindowEnumerator(getter_AddRefs
(winenumerator));
winenumerator->HasMoreElements(&bMoreElements);
// For all windows
while (bMoreElements)
{
winenumerator->GetNext(getter_AddRefs(supports));
winenumerator->HasMoreElements(&bMoreElements);
nsCOMPtr<nsIDOMWindow> domwnd;
domwnd = do_QueryInterface(supports);
if (domwnd == nsnull)
continue;
// Get the container window (nsIWebBrowserChrome)
nsCOMPtr<nsIWebBrowserChrome> webbrwsrchrome;
rv = pInstance->windowwatcher->GetChromeForWindow(domwnd, getter_AddRefs
(webbrwsrchrome)); // <- this is where the problem is. the returned pointer to 
the
                                                                               
                                                                     //    
webbrowser chrome is null
if (webbrwsrchrome == nsnull)
continue;
// From it get a pointer to the nsIEmbeddingSiteWindow interface
nsCOMPtr<nsIEmbeddingSiteWindow> embedingwnd;
embedingwnd = do_QueryInterface(webbrwsrchrome);
if (embedingwnd == nsnull)
continue;
// Call GetSiteWindow to get the HWND
embedingwnd->GetSiteWindow((void * *) &hwndBrowserWindow);
}



Reproducible: Always
Steps to Reproduce:

Actual Results:  
nsIWindowWatcher->GetChromeForWindow returns a null nsIWebBrowserChrome pointer

Expected Results:  
a valid pointer to the nsIWebBrowserChrome

This happens with the Windows version of Firefox too. 

I am marking this as a major bug. Some may disagree but since all source 
available on the internet that retreives the native window of the browser is 
almost identical to mine, and it doesn't work, I think this has to be fixed. 
Components should be able to do in Mozilla everithing that they can do in 
other embedders.
Summary: Maybe Mozzila does not embed Gecko correctly. nsIWindowWatcher->GetChromeForWindow returns a null nsIWebBrowserChrome pointer → Maybe Mozilla does not embed Gecko correctly. nsIWindowWatcher->GetChromeForWindow returns a null nsIWebBrowserChrome pointer
Product: Browser → Seamonkey

Comment 1

13 years ago
testcase: set signed.applets.codebase_principal_support->true, click on the URL
link.

tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050514 Firefox/1.0+

same problem reported here:
http://groups-beta.google.com/group/netscape.public.dev.xul/browse_thread/thread/230f1b93fe8e83b2*

making a wild guess as to what component this should be in.
Assignee: general → adamlock
Status: UNCONFIRMED → NEW
Component: General → Embedding: APIs
Ever confirmed: true
Keywords: testcase
Product: Mozilla Application Suite → Core
QA Contact: general
Summary: Maybe Mozilla does not embed Gecko correctly. nsIWindowWatcher->GetChromeForWindow returns a null nsIWebBrowserChrome pointer → nsIWindowWatcher->GetChromeForWindow returns null

Comment 2

12 years ago
Can anyone answer what is current state of this bug?
I also have a code like mentioned above and it does not work in Firefox 1.5.0.1.

Comment 3

12 years ago
Created attachment 217458 [details] [diff] [review]
Fix to NULL HWND

This is psuedo patch for the problem.

This is a diff -u of the old and new file.  Since I don't have the CVS tree I cannot produce the honest to goodness thing.  I hope this helps.

This problem occurs for me as well when the dialog embedding the ActiveX control is not visible and I attempt a print.  I tracked down the cause (in the ActiveX control) to a function called nsPrintingPromptService::GetHWNDForDOMWindow(), in nsPrintingPromptService.cpp.

I hacked, yes, hacked, since I don't have a good grasp of the embedding window structures this change.  This was made to Mozilla 1.7.5, as I have yet to update to the latest.

NOTE: I am not saying this is a fix, but it does work for me.  Your mileage no doubt will vary.  You may have to change your own code to reflect how this function attempts to get the HWND.

Cheers,
Graham

Comment 4

12 years ago
The bug is still here with xulrunner 1.8.0.4, here is a easier sample :

nsCOMPtr<nsIWindowWatcher> ww =
do_GetService("@mozilla.org/embedcomp/window-watcher;1", &rv);
nsIDOMWindow *active = NULL;
ww->GetActiveWindow(&active);
nsIWebBrowserChrome *chrome=NULL;
ww->GetChromeForWindow(active,&chrome); ==> chrome IS NULL !!!!!


PS : this is not a embedding bug !!!!

Comment 5

12 years ago
The bug is still here with xulrunner 1.8.0.4, here is a easier sample :

nsCOMPtr<nsIWindowWatcher> ww =
do_GetService("@mozilla.org/embedcomp/window-watcher;1", &rv);
nsIDOMWindow *active = NULL;
ww->GetActiveWindow(&active);
nsIWebBrowserChrome *chrome=NULL;
ww->GetChromeForWindow(active,&chrome); ==> chrome IS NULL !!!!!


PS : this is not a embedding bug !!!!
QA Contact: apis

Comment 6

a year ago
Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.