In the case you indicated, the main thread call stack probably includes the
invocation of the nested message loop. I think this nesting is usally
required because we enter a special windows message loop that handles native
windows (dialog boxes). We use some very fancy footwork to cause this
native message loop to actually provide time slices to service the Chrome
task queue etc.. As a result, until that native window terminates (user
clicks OK) there is no way for the basic browser process to terminate
(cleanly) as the main UI thread is still running.
When *finally* you do hit the OK button on the native dialog, then the
dialog will terminate, and (if you have "closed" the main browser window)
the main UI thread can unwind and the browser process can really terminate.
Typically a Quit() call to the MessageLoop sets the state to indicate that
the (current) loop should exit soon (when next it seems idle?).
...at least that was the way it was supposed to play out...
There is a chance that someone put in a nested message loop from Chrome for
a Chrome dialog. In that case, the multitude of Quit() calls at various
nesting depths could be (incorrectly) aggregated by a nested Chrome message
loop. Historically we've seen problems like that... but I thought we had
handled such (and strongly discouraged the use of nested message loops).
Looking at the UI, I can see the Options dialog; the Show-All dialog; and
the Are You Sure dialog. It would be most desirable if all of those dialogs
were native, and none involved a nested Chrome message loop. If there was a
nested Chrome message loop, extra care would be needed to be sure the extra
Quit() calls were not aggregated (losing the extra one).
So that's something to look at.
If the problem is as mentioned, we'd need to either stop using a nested
message loop, or be a little more careful in the nested message loop about
losing the extra quit message. A more traditional approach is to make the
last "Are You Sure" dialog application-modal, so that you can't terminate
the browser while it is displayed/pending (but I think we try as much as
possible to avoid modal dialogs).
At some point I recall looking at more targetted Quit() messages, that
terminate only a given MessageLoop, and also looking at counting the number
of Quit() invocations, so that the excess at a nested level propogated
upwards. I think it was decided that such situations would better be
avoided. (The count of the
number of Quit() messages can wreak havoc if a high level Quit() causes a
nested loop to terminate instead :-/ ).
Jim
p.s., Please cc me on the CL for any fix you decided on.
On Tue, Sep 22, 2009 at 10:47 AM, Peter Kasting <pkast...@google.com> wrote:
> On Tue, Sep 22, 2009 at 10:39 AM, Daniel Cowx <daniel.c...@gmail.com>wrote:
>
>> Can someone please provide a bit of insight into how to solve the
>> following problem:
>>
>> 1. Open Chromium > Options > Show saved passwords
>> 2. Click the "Remove All button"
>>
>> Now, *before* you click "Yes" or "No", close the main browser window
>> (e.g. by clicking the X in the upper right corner). When you do this,
>> all windows disappear, but the main browser process remains running.
>> It looks like this is due to a nested invocation of MessageLoop::Run()
>> (via chrome\browser\views\confirm_message_box_dialog.cc) and the fact
>> that Quit is only exiting the most recent invocation.
>>
>> How can we cleanly quit the application in this case?
>
>
> Explicitly CCing a couple people who know nested message loops best.
>
> PK
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
