> constantly is NOT a "fix" for this issue. > Not that I want to start a huge discussion about this, but leaving FF running Because I hate open an email or a RSS from mail and two stupid I love FF but more day I pass with this bug, I want go with > have this problem, but I'm really hates this bug and I can imagine that is not > C'mon after two months you just tell that is don't fix and a method for don't I think it would be good to find the bug in the command line code rather than plug in the old code to solve the problem. We could add back all the manual code for finding a window and properly opening the URL in response to the apple event but we'd essentially be duplicating the command line code, which shouldn't be necessary. I don't know why this would fail early on and I need to work on other stuff today so I'm documenting my debugging progress here. Return outDOMWindow ? NS_OK : NS_ERROR_FAILURE OutDOMWindow = do_GetInterface(docShell) InWindow->GetDocShell(getter_AddRefs(docShell)) GetDOMWindow(nsIXULWindow* inWindow, nsCOMPtr& outDOMWindow) That function, near the top of nsWindowMediator.cpp looks like this: NsWindowMediator::GetMostRecentWindow does find data (nsWindowInfo) for a most recent window, but it fails when calling GetDOMWindow with "info->mWindow". The problem is that the window mediator returns NULL. That calls getMostRecentWindow on nsIWindowMediator. This calls getMostRecentBrowserWindow, which calls getMostRecentBrowserWindow in nsBrowserGlue.js. I traced the failure to handURIToExistingBrowser, which is a js function in nsBrowserContentHandler.js. This should work, and it does after app startup. In the new code, we use nsICommandLineRunner and have it run with a "-url" argument.
In the old apple event handling code, for kAEGetURL, we manually looked up a window by enumerating by z order via nsIWindowMediator.
0 kommentar(er)
