New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 164 users
Status: Untriaged
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

issue tab-organizer:89

  • Only users with EditIssue permission may comment.

Sign in to add a comment
No way to detect when the browser is closed
Reported by, Dec 20 2009 Back to list
Chrome Version       : (Official Build 33992)
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: N/A
  Firefox 3.x: N/A
         IE 7: N/A
         IE 8: N/A

What steps will reproduce the problem?
1. Try to detect when the browser is closed

What is the expected result?
Such detection is possible.

What happens instead?
There is no reasonable way to detect this.

Please provide any additional information below. Attach a screenshot if
Please see  Issue 147 . This WontFix bug has been causing users a lot of 
problems and in some cases even prevented them from using Chrome. I created 
an Extension that warns the user when closing Chrome, preventing them from 
losing their tabs. You can view it here:

There is one problem, however: it can only detect keypresses. If the user 
closes Chrome via the "x" button in the upper right, or via the Wrench -> 
Exit menu, there is no way to detect it!

It would be nice to have a "chrome.browser.onClosed" event that is 
triggered when the browser is closed by any means ("x" button, Exit 
submenu, Ctrl+Q key combination). It should also be possible to use 
preventDefault or similar to stop the browser from closing.
Comment 1 by, Dec 20 2009
This would also enable an extension for clearing browsing data on exit, which would be 
Comment 2 by, Dec 21 2009
Labels: -Area-Undefined Feature-Extensions
Status: Untriaged
I just thought of something. Background pages are created when the browser is opened, 
and closed when the browser closes, correct? How about this:

You attach an "onbeforeunload" event handler to the background page, which will fire 
when the background page is closed (i.e. when the browser closes). You should then be 
able to call preventDefault to stop that from happening.

Though, I think a "chrome.browser.onClosed" would be good too.
Comment 4 by, Dec 22 2009
Labels: -Type-Bug -Pri-2 Type-Feature Pri-3
Status: Available
Labels: Area-Feature
Labels: -Area-Feature Area-UI
Comment 7 by, Sep 10 2010
Labels: Pri-2
Comment 8 by, Sep 10 2010
Labels: Mstone-X
Comment 9 by, Sep 12 2010
Status: WontFix
Comment #3 describes a reasonable workaround. I'm not sure if it actually works due to the way background pages are implemented, but if not, we should fix that bug instead.
@9: I'm almost completely certain that background pages ignore all DOM events, including unload and beforeunload. If beforeunload were implemented (including returning a string asking for user confirmation), then yes, this issue would be resolved.
Re comment #10: I think you're correct that background pages are not involved in DOM events. Injected scripts can add a beforeunload handler including support for a confirmation prompt string. These are severely restricted in their capabilities though, the script must decide immediately if it wants to prompt or not and cannot wait for a response from a background page before returning.

I filed  bug 55473  for the related issue that beforeunload handlers can't tell the difference between closed windows and other unload reasons such as script-initiated background reloads, this is currently causing false positives in my "Window Close Protector" extension that I try to work around with heuristics:
@11: Indeed, which is why supporting beforeunload in background pages would be nice. Especially since content scripts don't work on chrome:// URLs, etc.
Please re-open the bug, background page does currently *not* handle beforeunload event. So, has stated on #3, this issue should be investigated. As above, a preventDefault may have interesting applications.
@13: Unfortunately, there doesn't appear to be a CC or Owner for this issue, so it's likely nobody will notice it. You'd be better off creating a new issue for supporting "beforeunload" in background pages.
Nevermind, I already filed  Issue 63295 .
Comment 16 by, Nov 17 2010
Status: Untriaged
Reopening per Aaron's comment 3 above, and Erik's comment in  Issue 63295 .
Comment 17 by, Nov 17 2010
Whoops, missed a CC.
Status: Available
Sounds like Aaron and I disagree a bit here (beforeunload vs. a special purpose event).  We'll sync up and figure out whether this is something we want to address.
We absolutely need this feature before we can use Chrome for our Oracle ADF Web application.  We need to be able to call script on the page that makes an ajax call to the server BEFORE the window closes so that we can clean up server resource associated to the users session. (i.e lots of cached queries)   We don't want the event to fire when they leave the page since they are still using the web app.  We only want it to fire when closing the window without logging out and need to guarantee that the call is successful before the window closes.   We're currently using a custom version of Firefox that hides all of the browser menu's and toolbars.  It's locked in to a single web site and looks more like a windows app than a browser.  We would like to move to a more performant browser but need it to be more customizable for a rich client web application.
I would just like to point out, that regardless of whether you allow extensions to stop the browser from being closed, simply being informed before the browser closes would be useful to fixing a bug in my extension.

There could very well be state or event listeners (like chrome.tabs.onRemoved), that should be removed before the browser unloads, and a chrome.browser.onClosed event would allow for cleaning those things up. That is why it's important that the event fire before any tabs have been closed.

Having said that, allowing an extension to stop the browser from closing would also fix  issue 147 , though that may be less useful if said issue were fixed by Chrome.
My extension now has two features that are broken due to lack of this event. It listens to tabs.onCreated and tabs.onRemoved events, and then updates a counter, and also uses it to implement Tree Style Tabs functionality.

The problem is, when the user closes Chrome, it sends a tabs.onRemoved event for every tab, which messes up the extension's state. If there was a browser.onClosed event, I could listen for that and manually remove the tabs.onRemoved listeners, but right now I can't.

Alternatively, if Chrome didn't send tabs.onRemoved or windows.onRemoved events when closing Chrome, that might be acceptable as well.

P.S. My extension isn't interested in preventing Chrome from closing, it only needs a notification, like an event.
Cc: a deleted user
 Issue 50333  has been merged into this issue.
@pcx - Even if you don't want to delay/prevent shutdown, having an event that's guaranteed to fire will in fact delay shutdown, and for most users, they won't have any way of knowing what's causing Chrome to shutdown more slowly.  I also don't understand why having a browser shutdown event actually helps your particular case.  If all you're trying to do is to track open tabs, then what do you lose at shutdown?
@erikkay - As an example to support this case as to why I would like this ability, I created an extension to assist with locking unauthorized access to a profile:

I would like to make it so that when the user goes to close the browser it can save all the tabs that are open, so when the browser is reopened no tabs will be reopened until the user authenticates. I already have the code in for this (in my local copy of the extension), but no way to trigger the saving of tabs - except through use of a special button, but that would be too much of a nuisance for users to use on a regular basis.
In this case, waiting for browser shutdown is a bad plan anyway.  The browser could crash, their battery could die, etc.  Track tab create and close events and store state as you go and you'll have a more reliable system.
Touche - good plan.
Why can't the event be called on shutdown but hide the browser immediately so that it appears to shutdown quickly even though the process hangs around for another couple of seconds.  And then add a timeout so that the process is forced to exit if the process doesn't complete it's ajax call (other other work)  within 2-3 seconds.
Delaying shutdown is a bad plan for a variety of reasons.  It prevents users from quitting and restarting quickly.  It leads to unclean shutdown when the user logs out since most OS's kill processes that don't exit quickly.  There are some OSs which give even fewer guarantees about shutdown behavior.

It also wouldn't meet your desire of being guaranteed to be delivered.  Network outage, power outage, OS logout/reboot, browser crash, tab crash, process hang, etc. are all failure points.
I don't understand the concern regarding quitting and restarting.  Each Chrome window is a new process so a new one can be restarted immediately even if the other one hasn't completely shut down.  I realize the transmission wouldn't be guaranteed under extenuating circumstances but would be better than nothing and would work 99% of the time.  The ones that don't would be be cleaned up by the session timeout.  Our session timeout is 1.5 hours due to the nature of the app.  It is an internal company app that users log in and work on all day long but we want to log them out if they close the browser.
Comment 30 by, Apr 17 2011
Well, extension developers have various reasons to depend on the event.
Asides for that, I do think APIs would better keep consistent behaviors, especially when there are more than two windows/tabs, close one will just trigger the event very well; but not well when there is only one window/tab left. Agree?
@erikkay: Um... Chrome fires a tabs.onClosed event for *every single tab* when closing Chrome... this causes several seconds of slowdown for me. How would firing *one more* event be worse?

So... your whole point about "an event delaying Chrome" is completely moot. It already fires tabs.onClosed events when closing Chrome, and yes, it does wait for extensions to handle them before closing.

Okay, I'll explain things... in my extension, I am keeping track of tab state. This tab state is saved in localStorage, so it will persist between Chrome sessions. This all works fine, no problem. The problem is, when a tab is closed, I clean up the state for that tab. But Chrome fires a tabs.onClosed event for every tab when Chrome is closed...

Because of this, Chrome triggers the tab cleanup code every time the browser is closed, so the tab's state no longer persists between sessions. It's impossible for my extension to know whether a tab was closed because the user closed it, or because Chrome is closing. A browser.onClosed event would let my extension tell the difference, so it doesn't run the cleanup code when closing Chrome.

What this means is that no extension can save tab state. At all. Because Chrome fires a tabs.onClosed event for every tab when closing, this wipes out any state. This is pretty serious, since there's many reasons why an extension might want to save a tab's state between sessions.

Thus, there's 2 solutions:

1) Provide a browser.onClosed event.

2) Stop firing a tabs.onClosed event when closing Chrome.

Either solution is acceptable for my extension.
I'll note that extensions can still save tab state, but only if they don't listen to tabs.onClosed events... except that if you're saving tab state, you'll almost definitely be listening to tabs.onClosed events.

Also, if Chrome no longer fired tabs.onClosed events when closing, that would solve my particular use case with my extension, but wouldn't necessarily solve the problems other people are having.

So, question: since Chrome's been firing tabs.onClosed events for a long long time, and it hasn't caused massive complaining from users, what would be the harm of adding on a browser.onClosed event? Especially if Chrome stopped firing tabs.onClosed events? You'd be trading O(n) events for a single O(1) event. How is that slower?
@pcx - I understand the issue, thanks for the clarification.

There are a few other ways we could address your problem:
- provide "why" with onClosed events (filed as bug 79873)
- provide a session restore API (filed as bug 79872)

As to your point about tabs.onClosed already slowing things down, I'd be surprised if this is more than a marginal slow down.  It's not guaranteed to fire during shutdown, so my guess is that you're getting a subset of the events, and even then we don't guarantee that they're delivered or processed before the extension process is closed.  Anyway, I filed bug 79870 for us to investigate the current behavior, since it's definitely not supposed to slow things down.  The fact that it behaves so inconsistently is also a concern.

A "why" property for onClosed events would also be acceptable for my particular use case. If by session restore API, you mean allowing extensions to associate arbitrary data with tabs saved in session restore, then that *might* be acceptable as well... I won't know until I actually see the API.

In case it matters, I'm saving the "indent level" of tabs, just like the Tree Style Tabs extension for Firefox.
FWIW, I just did a test, and we do not currently wait for background pages to process the tabs.onRemoved events. We just start shutting down processes, and the background page gets shutdown at some non-deterministic time and may or may not have gotten a chance to see/process all the events. 

Comment 36 by Deleted ...@, Apr 24 2011
the windows.onRemoved Event can not work when there is only one chrome window. it is still a bug?
Chrome version 10.0.648.205
Comment 37 by, May 7 2011
I also want this feature.As I create an extension which need to logout before the chrome is closed,so that the server  let users login in another PC or system.
The server will record the IP or the system of the PC ,which run the browser with my extension,when users login.If users forget to logout themselves,the server will not let user login in another PC,as the server'records  note that the users are still in the login state.
I also want this feature as a user. I am wondering if chrome developers will be happier if extensions are required to ask for a new permission to receive the callback at the time of exit? This way, those users who are paranoid about their browser exit getting slowed down due to these callbacks could pay attention to this elevated permission and choose not to install an extension. I am not sure if I am clear enough, but thought of putting this idea forward to begin a discussion, in case it has any merit :)
Labels: Restrict-AddIssueComment-Commit
Thanks everyone for the feedback.  We have the information we need for this bug.  I'm closing comments, but feel free to star the bug if you want updates on its progress.  Also, note the other bugs mentioned in comment 33 above.
Labels: -mstone-x
Project Member Comment 41 by, Mar 10 2013
Blocking: -tab-organizer:89 tab-organizer:89
Labels: -Feature-Extensions -Area-UI Cr-Platform-Extensions Cr-UI
Comment 42 by, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 44 by, Jun 27 2016
Labels: Hotlist-Recharge-Cold
Status: Untriaged
This issue has been available for more than 365 days, and should be re-evaluated. Hotlist-Recharge-Cold label is added for tracking. Please re-triage this issue.

For more details visit - Your friendly Sheriffbot
Sign in to add a comment