When our JavaScript progress listener gets called at the end of a page
navigation, it passes an nsIWebProgress interface into our XPCOM
component. The XPCOM component then calls nsIWebProgress::GetDOMWindow.
A code snippet is shown below. Everything works as expected when
Firefox 1.5.0.4 is hosting a single tab. If 2 tabs are open (tabA and
tabB), things don't work like I'd expect.
If you switch to tabB while tabA is busy loading a page...
1) the JavaScript progress listener receives a STATE_STOP flag
immediately (tabA is not done loading the page, and tabB is not loading
a page)
2) the window pointer that you retrieve with
nsIWebProgress::GetDOMWindow (pDOMWindow in the code below) is for tabB
(NOT tabA) but the navigation wasn't occurring in tabB
Is this to be expected?
Thanks,
Roy
// ==================================
// JAVASCRIPT event listener
// ==================================
onStateChange: function(aProgress, aRequest, aFlag, aStatus)
{
if (aFlag & STATE_STOP)
XPCOMObject.navigatedTo(aProgress, aRequest, aStatus);
return Components.results.NS_OK;
}
// ==================================
// C++, XPCOM component implementation
// ==================================
NS_IMETHODIMP MyImplementation::NavigatedTo(nsIWebProgress
*aWebProgress, nsIRequest *aRequest, nsresult aStatus)
{
if (aWebProgress)
{
// Get the DOM window from the nsIWebProgress*
nsCOMPtr<nsIDOMWindow> pDOMWindow;
nsresult rv = aWebProgress->GetDOMWindow(getter_AddRefs(pDOMWindow));
// pDOMWindow represents the DOM window for tabB, even though
// tabA was the tab that was actually navigating to a page.
// Do something useful...
}
return NS_OK;
}
_______________________________________________
dev-tech-xpcom mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
