tqh ([info]tqh) wrote in [info]bezilla,
@ 2004-05-14 21:02:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Close All ( or the Almost there update) (or the How I learnt to use the nsIProxyObjectManager)
In Deskbar there is a, for Mozilla, little used menuitem called 'Close All'. Well not anymore. In my current build 'Close all' actually closes all the browser windows. Cleanly I might add, although it doesn't ask any questions first.

The reason it hasn't worked before is because of threading issues. So the main Mozilla thread doesn't agree with any outsider thread telling them to quit. But if a friendly Mozilla UI thread tells it to quit it does.

That's what the proxy does for us. Hopefully it will also do wonders for opening windows and embeddign. QuitRequested below...
  virtual bool QuitRequested() {
      nsresult rv;
      nsCOMPtr appShellServ = do_GetService(kAppShellServiceCID, &rv);
      if(NS_FAILED(rv)) return false;
      nsCOMPtr pIProxyObjectManager = do_GetService(kProxyObjectManagerCID, &rv);
      if(NS_FAILED(rv)) return false;

      nsCOMPtr appShellProxy;
      rv = pIProxyObjectManager->GetProxyForObject(NS_UI_THREAD_EVENTQ, NS_GET_IID(nsIAppShellService), appShellServ, PROXY_ASYNC | PROXY_ALWAYS, getter_AddRefs(appShellProxy));
      if(NS_FAILED(rv)) return false;

      (void) appShellProxy->Quit(nsIAppShellService::eAttemptQuit);
  }



(Post a new comment)

Opening windows
[info]tqh
2004-05-14 07:29 pm UTC (link)
Works great now.

Launching first Mozilla and then doing 'mozilla http://www.bebits.com' actually opens BeBits in the first browser.

So except Drag'n'drop it's almost a full native app.

(Reply to this) (Thread)

Re: Opening windows
[info]kokimare
2004-05-14 07:57 pm UTC (link)
Hey, tqh, this is great news!

Does this mean that defining Mozilla as the default browser will now work in BeOS?

We want a new build! :-)

Koki

(Reply to this) (Parent)(Thread)

Re: Opening windows
[info]tqh
2004-05-14 09:25 pm UTC (link)
Yes, at least on my system. I have a build here that works perfectly.
Opens With works great (even for multiple files)
Doubleclicking html-files works fine
'Close All' does just that

There is a BONE-build on BeShare: Mozilla-i586-pc-beos-20040509-BONE-NATIVE_APP.zip

(Reply to this) (Parent)(Thread)

Re: Opening windows
[info]tqh
2004-05-14 09:33 pm UTC (link)
Currently there is one bug. Doubleclicking a file when mozilla isn't running opens the ordinary start-page.

(Reply to this) (Parent)

Opening bookmarks
[info]kokimare
2004-05-15 01:39 am UTC (link)
I have a question: if you were to make Mozilla visible to "x-vnd.Be-bookmark" would you not be able to open bookmarks as well? I think that is what we would want. Can this be done?

Koki

(Reply to this) (Thread)

Re: Opening bookmarks
[info]tqh
2004-05-15 06:59 am UTC (link)
We need to extend RefsReceived so it knows what to do with a bookmark. It shouldn't be that hard.

(Reply to this) (Parent)

The lin where I found this wonderful proxy
[info]tqh
2004-05-15 02:55 pm UTC (link)
http://www.mozilla.org/projects/xpcom/Proxies.html

(Reply to this)

is this situation description correct?
[info]fyysik
2004-06-18 08:38 pm UTC (link)
"So the main Mozilla thread doesn't agree with any outsider thread telling them to quit".

What i see. be_app in nsAppRunner.cpp receives B_QUIT_REQUESTED. And also calls hook QuitRequested(). Your (working) code confirms that too. But then default implementation of this method should send B_QUIT_REQUESTED to all app windows. Thus, fire there Window::QuitRequested hooks.
Which don't happen at proper moment. If you tried to trigger QuitRequested from Deskbar, this message don't reach WIndow until you hit, for example, close button at yellow tab. In this case Window receives two messages. One from close button, and second, if it was last/single window - that old pending/forgotten QuitRequested from be_app's QuitRequested.

Actually, i don't understand how main-mozilla-thread "customs/disagreements" can affect BMessages throughpass in this case.
I rather see here problem with messaging reimplementation over ports ('natv' case) or some bug with semaphores, related to message flow.

(Reply to this) (Thread)

Next group of notices
[info]fyysik
2004-06-18 08:49 pm UTC (link)
There is already several BeOS bugs at bugzilla related to this issue, IIRC (but maybe not), where i used word "zombie".
1)Sometimes Mailnews leaves ComposeMessage in zombie state after mail was sent. such window don't react on any attempt to close or activate it. And it persists until whole Mailnews is closed, or maybe whole Mozilla
2)Find dialog issue #1. Sometimes when it cannot find string on page and throws alert about that, pressing OK on alert freezes all - alert itself, find dialog and whole mozilla. It releases after some long time, but frequently also leaves half-hodden zombie of find dialog.
3)(find) Dialogs issue #2. Raise Find dialog. Close "parent" window. Dialog stays. As whole main thread (mozilla-bin) - until you close dialog explicitly.

Continue...

(Reply to this) (Parent)(Thread)

Observation
[info]fyysik
2004-06-18 08:54 pm UTC (link)
I think that you have to investigate thing more deeply than me, but one impression remains to be said:
I got feeling that mozilla-bin thread is associated with special BWindow - little and hidden most of time. You may notice it sometimes in left-upper corner of screen. And i have suspects that lot of our problems are related to behaviour/event handling in this window, maybe just due it's hidden state.

Resume. Honestly, i acept at moment "nativity patch" and related rather as hack, until we get good understanding about described issues.

(Reply to this) (Parent)(Thread)

Re: Observation
[info]tqh
2004-06-19 12:52 pm UTC (link)
Yes, it's more of a hack than a final solution. When it comes to 'close all' we don't go ask the BWindows if they want to quit (as they always says no, probably due to some internal things in nsWindow). Instead we uses Mozilla's own way to ask all windows to close. This is a hack until someone fixes proper nsWindow QuitRequested.

When it comes to opening windows it's also a hack. I make sure I call openWindow on the UI thread, which I shouldn't have to. At least not according to other platform's code.

The only thing that isn't really a hack is the movement of the Be App from nsAppRunner to nsNativeAppSupportBeOS.cpp and some NativeApp functions that are implemented.

The current patch is more of a Proof of Concept. It cannot be taken further without making the nsWindow (and friends) less prone to locking and with correctly implemented Be API hooks (like QuitRequested returning true).

(Reply to this) (Parent)


Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…