Closed
Bug 246632
Opened 21 years ago
Closed 9 years ago
nsIWindowWatcher->GetChromeForWindow returns null
Categories
(Core Graveyard :: Embedding: APIs, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: mihail, Assigned: adamlock)
References
()
Details
(Keywords: testcase)
Attachments
(1 file)
904 bytes,
patch
|
Details | Diff | Splinter Review |
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.
Updated•21 years ago
|
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
Updated•21 years ago
|
Product: Browser → Seamonkey
Comment 1•20 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
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•19 years ago
|
||
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 !!!!
Updated•16 years ago
|
QA Contact: apis
Comment 6•9 years 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
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•