Arachnophilia 4.01/28/2024 ![]() Not all system sessions require the use of Firefox thus, need Firefox taking up valuable display space. Also leaving Firefox open means having a Firefox window always present when Firefox is in use or not. That "leave Firefox open" is not an acceptable solution, especially from a system cold start or restart. The comment "leave Firefox open" is a little hard following system shutdown and then opening from a third party following startup. I therefore uphold that it is not working properly. After I received an email saying elements in my last post was nonsense I did some testing and I can actually close the window with its' button, but still not with the above mentioned shortcut. I must correct myself: When pressing Cmd+W shortcut in OS X 10.5.8 the last window of Firefox will not close. > application does something as unexpected as that, many people stop trusting it > bug, but I have no technical background to back me up, though. > in FF yet leaving the application running. ![]() > that, contrary to other OS X browsers, it is not possible to close all windows This "extra window" is annoying, and it is also a fact When an application does something as unexpected as that, many people stop trusting it per se. This must somehow be related to this bug, but I have no technical background to back me up, though. This is a serious drawback when you scroll through active windows in OS X. This "extra window" is annoying, and it is also a fact that, contrary to other OS X browsers, it is not possible to close all windows in FF yet leaving the application running. > switching to Safari until this problem has been resolved. > however, I'm beginning this speculate that more and more Mac-users are > (or sincerely hope) that the great FF-crew is working on a permanent solution. > I too is very disappointed that this issue has not yet been resolved. > 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 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |