Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 25 users
Status: Fixed
Closed: May 2010
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Feature

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Update available notification
Reported by, Nov 17 2009 Back to list
In some cases, users go for weeks on end without restarting their browser. 
They are missing important updates often containing security fixes. To 
encourage users to update, we should show some UI when there has been an 
update available for 2 weeks:
*Badge the wrench menu icon with a little warning triangle and "!". 
*Add the same badge beside the "About Google Chrome..." menu item.
*Change the text to "Update Google Chrome..."
*This menu item launches a dialog that says: "Old school's not cool. Google 
Chrome is woefully out of date because it hasn't crashed or restarted in at 
least two weeks. Restart Chrome to apply update. [Restart and update] [Not 

Comment 1 Deleted
Comment 2 Deleted
As I said in the bug that I duped into this, notifications on the wrench menu won't work 
on OS X because chrome/mac doesn't display the wrench menu by default.
Comment 4 by, Dec 2 2009
Perhaps we should add an icon/button to the right of the URL bar on mac for this case 
then. Clicking it would bring up the "old school" dialog.
I like the icon to the right of the URL bar idea. Perhaps for a security update we 
could do an immediate infobar?
Comment 6 by, Dec 2 2009
One thing to keep in mind: on the Mac, the application can be running with no browser 
windows open.

Also, let's clarify: we're talking about an “update was installed” notification, not just an 
“update available” notification, right?  “Update available” doesn't make any sense: all of 
our background checks will install the update if one is available.
mark: While it's possible that chrome is running without windows, everyone who uses 
chrome will have at least one window open. I think putting something on the browser 
window is sufficient even on OS X.
Comment 8 Deleted
Comment 9 by, Dec 20 2009
RichardO suggested in #chromium that we could add a badge to the dock icon on OS X. 
That sounds like a good solution to me.
Comment 10 Deleted
Comment 11 by, Jan 22 2010
If we do a dock icon, then I'll take care of the Mac impl given I've done the other
dock work. Do we have UX guidance as to the badging that we would want? Is there an
existing signal within the app to let us know we need a restart?
Comment 12 Deleted
Comment 13 by, Jan 22 2010
There isn't an existing in-app signal yet unless the user's visited the About window, but 
we shouldn't tie this to the About window, this is about something else.  We already do 
display "gotta restart" UI when the About window opens.
Labels: -Area-Feature Area-UI
Comment 15 by, Apr 1 2010
Labels: -Mstone-5 Mstone-6
The restart should also restore the user's session.
Comment 17 by, May 2 2010
If the mac is running with no windows open when an update becomes available, it seems like we could just 
restart Chrome immediately.
fwiw I don't know if the "grace period" after which we show an infobar should be the 
same for all users. I don't close my browser, unless it crashes. My computer at home 
I "sleep" and never shut down (so again, I never close Chrome unless it crashes). So, 
for me, you are going to infobar me on every update, it's just a question of whether 
it's immediate or delayed by N days -- so, you might as well infobar me right away 
and keep me secure.

I think this "grace period" could be determined locally, not globally, as a function 
of the inverse of the average time the browser is left open for that particular user. 
For users who leave the browser open forever, infobar them right away (because you 
are going to infobar them before they would normally close their browser, delaying 
won't make it less annoying, so might as well get it over with). For users who close 
their browser frequently, infobar them after a longer time period, because we believe 
with some non-negligible probability that they will close their browser "soon" of 
their own accord.

Comment 19 by, May 2 2010
On the Mac, we really can’t just restart the app just because there are no windows. That comes with too many 
problems and behavior changes.
Comment 20 by, May 3 2010
Mark, can you humor me and point out some of these issues?
Comment 21 by, May 3 2010
We can’t take control of the application process lifetime out of the user’s hands on the Mac. We can’t start 
bouncing dock icons willy-nilly in the background for a restart (that is, a restart isn’t actually silent or 
unobtrusive) or tolerate app activation switches (that is, a restart doesn’t necessarily have no impact on 
whatever else the user is doing). We can’t dump session cookies or HTTP auth data (presumably this is 
solvable, but we can’t have a world where sometimes an app left alone with no windows remembers logged-in 
sites and other times it doesn’t). We can’t kill downloads in progress (even with resume, it’s not idiot-proof).

Fundamentally, the problem with the approach is that on the Mac, a UI application is its own first-class entity, 
and there are certain assumptions about what that means, and certain visual feedback cues that reinforce 
those meanings. There’s no direct analogue in the Windows and Linux models, where there’s no “UI 
application” per se, you’ve just got a process (or a bunch of processes), and a window (or a bunch of windows, 
or zero).

None of these things are really a big deal if there’s an infobar or something else that offers “restart?” and does 
it on the user’s behalf if the user says “sure.”
I'm 110% behind Mark on this one.
Comment 23 by, May 3 2010
I agree Mac with no windows is equivalent to having windows open as far as a signal goes.

If we can solve this problem for Windows somehow, which only exists when there are browser windows open, we 
should have something that'll work for all platforms.
 Issue 42536  has been merged into this issue.
Ok..all jokes aside. The average user (not tech-savvy users) also need to know what new features 
each upgrade brings, if they have any. The average user who gets auto-updated or even those who 
manage to manually update do not know about/are not interested in checking the Google blogs to 
learn, marvel and use the features which have been added to Chrome in a standard way, or which are 
exposed in a different way. When Chrome is updated, there should be something which shows the 
average user the new features and major bug fixes as is done in other browsers. Please schedule 
this feature along with this issue appropriately. Also, if possible, a temporary solution should be 
put in place for Mstone-5 to prevent AVERAGE users who are updated (and don't know what the new 
features are) realizing Chrome has been updated a few weeks/months later by stumbling across 
something new (or even something that has been present but just didn't know was there due to this 
issue) and going on a wild goose chase to figure out what has been added.

Thank you in advance.
#26, I'm not certain what jokes you're referring to, but feature discovery is a 
distinct problem.  Users who don't want to follow Chromium blogs also don't want to be 
bothered every couple weeks about a trivial new feature which has been added (*).  
This bug is more about making sure people don't run for long periods and miss out on 
implicit features like security fixes and "bug fixes".

(*) I'll go one more - I actively hate programs which demand my time to tell me about 
their trivial new features.  As a programmer, yes, I want people to know about that 
thing I just spent 6 weeks working hard on.  But as a user, I don't use programs in 
order to stroke programmer egos.
Comment 28 by, May 5 2010
#27, Unfortunately, unlike yourself, the majority of average users (including myself and all those who I've recommended 
this program to) are not bothered because although new features are added to Chrome every few weeks or so, the STABLE 
build is updated every few months. A few seconds of your valuable time every month to know when features are added and 
how to use and access them is not a problem for the average user. Maybe this is a problem for you, but I'm sure if you 
converse with other users and even developers, you would find your views are different from the main user base (as also 
proven by a part of a survey which I conducted on the 157 users I know who use Chrome). When an average user is auto-
updated or updates manually..that's it. There's no automated way (via a page which is shown or a link in the about box), 
to show important bug fixes or new features (every few months), some of which are present in another browser they use 
alternatively or previously. The average user should not be expected to update Chrome manually (problem solved via auto-
update) and to actively search for a release notes page or something equivalent for an average user, which shows any 
features and important bug fixes which have been added. They need a way to see which features are added and how to 
access and use them, as sometimes Chrome implements features in a different way to other browsers.

Fortunately, because chrome is updated every few months, if (and when) something like what I described previously is 
added, it will only take a few seconds to read about new features and major annoying bug fixes which is not much 
demanded "time" (to the average user at least..). Also, unfortunately, none of what I said bears any resemblance with 
the phrase "stroke programmer egos"..
Status: Started
A comment plus a question for Brian:

Re: InfoBars on security updates: We don't currently have a way to ask Omaha if the 
version that got installed in the background was a security update (to trigger the 
infobar). Doesn't mean we cannot do it; we just need to change Omaha and our release 
process to add such a flag. Probably better to file a separate bug for it if we want 
to proceed on that, but I'll make sure we don't exclude that option while 
implementing what Brian asked for.

Brian: If the user selects Not now, does the menu item revert back to About Chrome? 
Does the notification timer start again (2 weeks)?
Don't almost all stable channel updates contain a security fix of one kind or another? 
Do we have stats? Dev and Beta channel users might appreciate notification of updates 
so they know to restart to get bug fixes and features.
> Don't almost all stable channel updates contain a security fix of one 
> kind or another? 

If you are arguing for showing the Infobar all the time (or all the time on the 
stable channel), we can certainly do that. If we want to differentiate between 
feature vs security updates, then we need a signal.

> Dev and Beta channel users might appreciate notification of updates 
> so they know to restart to get bug fixes and features.

I believe this is orthogonal to whatever UI presentation we choose, but I think the 
scheme I'm pursuing would deliver those notifications to beta and dev users also 
(need to verify though).
Comment 33 by, May 21 2010
Glad you are getting started on this! 

I don't think we want an infobar. Somehow, that crept into the comments, but it's never been the 
desired UI. It's supposed to be a badge on the tools menu that leads to a dialog. I don't see how 
the badge on the Mac dock works because there's nothing to click to get the "old school" dialog.

If the user clicks "Not now" I think we should just dismiss the dialog but keep the badge and the 
menu text as a persistent reminder that Chrome is out of date. 
> I think we should just dismiss the dialog but keep the badge and the 
> menu text as a persistent reminder that Chrome is out of date. 

Sounds fine. This of course means (since the About menu item is replaced) that you have 
no way of getting to the About box, but that's probably a minor issue...
Comment 35 by, May 21 2010
Maybe we should open the about box along with this dialog in front of it.
Essentially, we should replace the old "You need to restart for this change to take 
effect" with this new dialog... Maybe reword it a little...?
Comment 37 by, May 21 2010
Yes, that dialog should have a button that actually shuts down Chrome. Ideally, it 
would restart it and restore the open pages, but I guess that's another bug. I filed for it.
I thought we were going to use an HTML notification for updates. I think I'd prefer 
It would be good to have a decision on the notification UI part soon. I started working 
on the dialog already, but can focus on the other parts of this changelist while we 
decide whether to use it or not.
Comment 40 by, May 21 2010
Keep in mind that the page and wrench menus are hidden by default on the Mac. If the plan is “badge one of 
those,” we’ll have to come up with something else for the very common Mac case: “they’re not there.”
Comment 41 by, May 21 2010
Linus, we are going to use an HTML notification when Chrome cannot update because 
Omaha is blocked. In the case where you have an update ready but you just need to 
restart, we decided that it would be better to show something more passive.

Mark, we talked about adding an icon to the toolbar when the menu icons are hidden. I 
still think that's the best solution. Also, Nicholas is working out a plan for 
consolidating the two menus into one. At that point, we were going to suggest that 
mac just shows the menu icon by default which would eliminate this special case.

Finnur, I think Nicholas is the right guy to talk to for the badge graphics as well 
as the special mac icon that we'll use in the short term. Alternately, you can just 
wait until we do the menu consolidation and avoid this special case.
Mark, Brian: avi showed interest in adding a dock icon for the Mac.

Avi: I'm adding a signal in an upcoming changelist (probably a notification) which you 
use to trigger the badge to appear.
Comment 43 by, May 21 2010
OK. I was pointing out that _if_ we wanted to do an icon I'd pitch in. Is this what
UX wants?
Comment 44 by, May 21 2010
Labels: -Pri-2 Pri-2Is
I still do not understand what the point of the badge in the dock is. I think it's a 
red herring. We want a badge on the menu, or, where there is no menu, a new icon 
(nicholas to design).
Comment 45 by, May 21 2010
Brian, Mac Chrome may be running with no windows open, and with no windows, there’s no opportunity for the 
user to see a badged menu or other icon. I think that’s where the suggestion to badge the dock icon has come 
Note that with support for application BackgroundContents we'll soon be able to run with no windows open on 
Win/Linux also.

There is also support for systray/status tray icons now, so one could use those instead, but I agree that the dock 
icon is a better solution for Mac.
Comment 47 by, May 21 2010
Mark, sorry for not responding explicitly to this earlier, but I do not think it's 
important to consider the no-windows-open case. If the user ever browses with Chrome, 
they'll have a window open. If they aren't actually using Chrome, then there's little 
risk to them having an old version running. In other words, I agree with thakis.
Comment 48 by, May 21 2010
thakis said “it’s fine to not worry about the no-windows case, oh wait, someone suggested badging the dock 
icon, we should do that.”

There is some amount of background stuff that we support or will support soon, so I wouldn’t say that the no-
windows-open case means that the user isn’t using Chrome.
Also, I forgot when writing my comment above that on win/linux we auto-restart if there's an update and no 
window is open. So I guess that use case is covered.
Can we get some mocks about what the toolbar item will look like? How will the user differentiate between this 
icon and an extension? Even for the dock icon, coming up with something meaningful we can badge the icon with 
is troubling me.
Comment 51 by, May 24 2010
I was suggesting something like the attached. I think that having a simple colored dot will help,  and the update 
available item will have the square, orange badge to match it. I was thinking it could pulse ever so slightly like an 
amber light.

9.1 KB View Download
Comment 52 by, May 24 2010
Labels: -Pri-2Is Pri-2
The following revision refers to this bug: 

r48115 | | 2010-05-24 19:14:36 -0700 (Mon, 24 May 2010) | 8 lines
Changed paths:

Add a couple of images for my upcoming changelist so I 
can use the try servers to try my changes.

BUG= 27941 
TBR=Nicholas Jitkoff

Review URL:

The following revision refers to this bug: 

r48318 | | 2010-05-26 13:11:54 -0700 (Wed, 26 May 2010) | 30 lines
Changed paths:

Implement upgrade notifications.

When we detect that the installed version is newer than the version you are
running we show a little throbbing orange dot over the wrench menu.

If you open the wrench menu and close it again, the throbbing will stop.

However, if you look at the contents of the wrench menu you'll notice that
the About box menu item has been removed and in its place is a menu item
"Update Chrome Now" with a bright orange icon to draw your attention to it.

Clicking on the icon shows a dialog box asking whether you want to restart
Chrome. If you do, the browser restarts with your session restored 
(even if you have Session Restore turned off).

Known issues:

- Currently this is Windows only. We'll have to port this to Linux and do
something differnet for Mac (which doesn't have the wrench menu).

- Showing an icon in front of Update Chrome causes the checkbox for the
bookmark bar menu to go away. Given that we will soon redesign the menus I'm
not going to spend much time trying to fix it.

BUG= 27941 
TEST=Wait for Chrome to be upgraded in the background, an orange dot should
appear over the wrench menu and if you select Update Chrome your session should
be retained.

Review URL:

Labels: -OS-All OS-Mac OS-Linux
Status: Available
This has been checked in, as you can see.

For testing purposes we'll check an hour after starting up Chrome and we'll notify the  
user immediately (this should be changed before we leave dev/beta to check once a day 
and notify the user 2 weeks later, if the user hasn't restarted yet).

Ben mentioned in the review that we have plans to turn on the page/wrench menu by 
default for all platforms, so the same scheme should work across platforms.

Avi/whoever: I mentioned earlier in this bug that I'd be providing a signal to listen 
for, but of course it turns out checking for upgrades is platform dependent, so the 
only signal is UPGRADE_RECOMMENDED, which is not sent on Linux or Mac at the moment. 

I won't be able to port the platform specific parts of this changelist to other 
platforms, so I'm releasing this bug back into the wild.
Comment 56 by, May 26 2010
Labels: -Type-Bug -OS-Mac -OS-Linux Type-Feature OS-Windows
Status: Fixed
Leaving the bug as-is isn’t useful for engineers or QA.

 Bug 45147  for Mac.
 Bug 45148  for Linux.
This one’s for Windows, and it’s fixed, r48318.
OK. Thanks, Mark, for picking up my slack.
I don't know if this is related but ever since I installed build 48348, I've been 
getting this little orange dot on the settings wrench and a message that I need to 
update since it's been "two weeks" since it crashed or restarted. I installed build 
48357 and it still shows the orange ball and the update chromium dialog, where about 
should be. Clicking restart and update restarts chromium but does NOTHING else.

Just one question, who's the person responsible for this untimely April Fools Joke of 
a function? Do you even think about how many people are going to be freaking out over 
the thought of a virus or malware infection because of this?
Comment 59 by, May 27 2010 - this is an in development feature, stay tuned for tweaks and 
Thank you for the report. I am the person responsible for implementing this. :) Sorry 
for causing alarm. :)

I had a similar report from my coworker today and I found an issue that could explain 
what you are seeing (uninitialized member variable). I checked in a fix a few minutes 
ago (revision 48363), which is still building.

If you could try that (once it is ready) and see if this feature works any better with 
my fix. If not, I would need to get some more information from you to try to reproduce 
the problem: what versions of Chrome you have installed, and where you got them from 
(Google Pack, downloaded from, downloaded from our buildbot, etc). If you 
have any side-by-side installations of Chrome that would be good to know also (if you 
don't know what those are you probably don't have one). 

It would probably be best to capture that info in another bug. Feel free to email me 
directly when/if you have created the bug.
Given how Chromium lacks Chrome's update infrastructure, I'm curious about how useful 
this function would be for Chromium, and what you devs intend to do with it.

Also, now that this bug has been marked as fixed and closed... will anything be done 
about the update notification on Chromium? Currently all it seems to do is restart 
Chromium if you confirm the "update", and nothing else besides - other than make the 
notification go away for a few seconds before it starts annoying the user again.
Okay, the fix put in by finnur is working. I don't see an update notification on the 
wrench, nor replacing the about dialog for 6.0.418.0 (48377). So I'm rather relieved 
now. I should have mentioned that I'm using Windows 7 x64 (and would love to see a 64 
bit version of Chromium, but that requires a 64 bit version of flash). 
Comment 63 by, Jun 13 2010
Bug on this:
  If a computer is left turned off for two weeks, then booted up and chrome is run, this orange badge shows.

Thats because chrome is started before the googleupdate program gets to update chrome.

I suggest instead the huristic for this is made to be:

if (app_running_time > 2 weeks && update_available) show_update_notification();

This solves the problem of a computer turned off for two weeks, and also solves the problem of comment 18.
Old school's not cool. Google Chrome is woefully out of date because it hasn't crashed or restarted in at 
least two weeks. Restart Chrome to apply update.

This error message is wrong. I exit chrome completely every day. So the part that says at least two weeks is definitely wrong.

Using 6.0.427.0 (Official Build 49010) dev

Project Member Comment 68 by, Oct 12 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 69 by, Mar 10 2013
Labels: -Mstone-6 -Area-UI M-6 Cr-UI
Project Member Comment 70 by, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment