Closed Bug 246632 Opened 21 years ago Closed 9 years ago

nsIWindowWatcher->GetChromeForWindow returns null

Categories

(Core Graveyard :: Embedding: APIs, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: mihail, Assigned: adamlock)

References

()

Details

(Keywords: testcase)

Attachments

(1 file)

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
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
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.
Attached patch Fix to NULL HWNDSplinter Review
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
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 !!!!
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
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
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: