Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 125965 After browser crash chrome is unable to restore the session if chrome is not set as default browser before crash.
Starred by 3 users Project Member Reported by, May 2 2012 Back to list
Status: Archived
Owner: ----
Closed: Aug 2015
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Sign in to add a comment
Version: 19.0.1084.41 (Official Build 134854) m
OS: Win7

What steps will reproduce the problem?
1. Install chrome 
2. Under Wrench--> Settings--> Onstartup "Open the New Tab page"
3. Open the test pages.
4. Crash the browser 

What is the expected output?
--After crash from the dialog box select to relaunch chrome should restore  chrome session.

What do you see instead?
--On relaunch it's navigated to the sign-in promo page with Set chrome as Default browser infobar. There is no "Restore" info-bar.
--I suspect "Default browser" info bar is taking precedence and not letting the "Restore" info-bar to show up. 

This is not regression.
--Linux and MAC it works fine.
Labels: Mstone-19 ReleaseBlock-Stable
Comment 3 Deleted
--I have checked on previous builds on M19,Its the same behavior.
--Once chrome is made as default browser everything works fine.
Comment 5 by, May 2 2012
Did the sign-in promo exist before M19?
yes, it exists on M18.
Comment 7 by, May 2 2012
Does M18 have this same bug, then?
Yes, Even M18 has the same bug.
Comment 9 by, May 2 2012
Ok, thanks for the information and the bug report. :)
pkasting: This might be a generic infobar bug (haven't investigated). (My question about the sign-in promo was misguided, this doesn't seem to be related to it, just that having 2 info bars at the same time doesn't work.)

Why releaseblock-stable for M19, if this is not regression but a bug that has always existed?
Labels: -Pri-1 -Mstone-19 -ReleaseBlock-Stable Pri-2 Mstone-21
Owner: ----
Status: Available

this does not look like a release blocker for M19. I agree it's something we should fix for the next release (M21), but a) it seems like it's not a regression and b) the issue only arises if Chrome is not the default browser and Chrome crashes.

Let me know in case there are implications I might be missing.

The infobar system does not mandate one infobar at a time.

AFAIK the default browser infobar has no way to block unrelated infobars from appearing.
Project Member Comment 13 by, Mar 10 2013
Labels: -Area-Internals -Feature-Sessions -Mstone-21 M-21 Cr-Internals Cr-UI-Browser-Sessions
Status: Archived
Archiving issues attached to old mstones, which haven't been touched in over a year.
Sign in to add a comment