- #Adium for mac os x 10.5.8 manual
- #Adium for mac os x 10.5.8 code
- #Adium for mac os x 10.5.8 windows
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.
#Adium for mac os x 10.5.8 windows
> 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
#Adium for mac os x 10.5.8 code
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.
#Adium for mac os x 10.5.8 manual
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)
