Window restores on relaunch after being closed |
|||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Steps to reproduce the problem: 1. Have at least one tab open and "Continue where you left off" enabled in settings. 2. Close it by clicking the window's close button (for one or more tabs), the tab's close button (for a single tab), or cmd+shift+w. 3. Quit and relaunch Chrome. 4. Repeat steps 1-3 but use cmd+w to close all tabs instead. What is the expected behavior? In either case, the window should not be restored since it was closed before quit. What went wrong? - When the window was closed with cmd+shift+w, the window close button, or the last tab's 'x' button, the window comes back on relaunch. - When the window was closed with cmd+w, it does not come back on relaunch. Did this work before? No Chrome version: 53.0.2772.0 Channel: stable OS Version: OS X 10.11.5 Flash Version: Shockwave Flash 22.0 r0
,
Jun 20 2016
Unable to repro this issue on MAC (10.11.5) for Google Chrome Canary Version - 53.0.2773.0 Screen-recording is attached. @sdy: Please have a look at the attached screen-recording and let us know if the procedure followed is correct. Else, please provide us the screen-recording for better understanding. Thank you.
,
Jun 20 2016
I've seen this from time to time, but it's not easy to repro. I think pawliger saw it too.
,
Jun 20 2016
We seem to have regressed on restoring minimized and maximized state. Also if you change the minimized state or z order of windows during session restore we seem to force the window back to the original minimized state or z order when we shouldn't
,
Jun 20 2016
@rnimmagadda, it looks like this only happens if it's the last open window. That was the difference in your test. Screen recording attached (had to compress it to get <10MB, sorry).
,
Jun 20 2016
Thank you for providing more feedback. Adding requester "rnimmagadda@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 20 2016
,
Jun 21 2016
I tracked down and fixed several possibly-related bugs last year (see Issue 535645 , Issue 536201 , Issue 536280 ). My first thought is that someone may have made changed around the code I fixed, so once you figure out which source files most-likely contain the bug you might look at their change logs for recent changes. That's if you don't have a set of repro steps.
,
Jun 21 2016
Happy to demo - can repro 100% with my session restore (about 8 windows, ~20 tabs)
,
Jun 21 2016
@pawliger: Can you repro with multiple windows? I only have a test case for the last window (i.e. a window only comes back incorrectly if I close *all* windows, and then only the last one closed comes back.). Either way, I'm going to start working on this (and claim the bug as soon as I get my chromium.org account set up).
,
Jun 21 2016
As I said in #9, I can repro 100% with multiple windows.
,
Jun 21 2016
Sweet. Please post instructions and/or that demo when you have a chance.
,
Jun 21 2016
,
Jun 21 2016
,
Jun 30 2016
@pawliger, if you have a test case and/or demo for multiple windows, send it over.
,
Jun 30 2016
See https://drive.google.com/open?id=0BwnThP3xKNFlVFJVRGU5NFRxbjg for a 1:30 experience of me quitting and launching Chrome dev and seeing 1) windows restore in different state than they were on quit 2) windows spontaneous activate, change z order, and maximize after I've minimized them during restore
,
Jul 5 2016
@pawliger: Sorry for the lag, I've been OOO with spotty internet. I think you found a separate issue — I've been seeing the symptoms in this bug for a *long* time; it's not a recent regression like what you demonstrated. Regardless, I can reproduce it reliably on dev and canary, and not on beta or release — so last known good is 52.0.2743.60, first known bad is 53.0.2783.5. I still have spotty internet so I can't do much searching or bisecting (also, having been on the team for ~1 week, I've never needed to pin down a regression among 7737 commits :) ). If you could file this separately or find an existing report (and cc me, I'm interested), maybe someone else could take a look — if they're in NYC, maybe I can peek over their shoulder while they track it down.
,
Jul 7 2016
Hey sdy@, For pawliger@'s bug, would you please go ahead and file that in a new bug? Especially if you're able to reproduce the problem at will, filing the bug yourself will ensure that your steps get captured, along with whatever other notes you have about the issue (regression range, etc.). When you file the bug please add me to the cc list and I will send you steps next steps on finding the cause. There's a tool that should be able to help you further pin down the regression range so that you're not digging through several thousand commits.
,
Sep 26 2016
,
Oct 5 2016
,
Dec 1 2016
,
Dec 29 2016
Migrating to more generic platform label, so that it can be applied to other platforms (i.e. I love the idea).
,
Feb 23 2017
,
Feb 23 2017
,
Nov 1 2017
,
Sep 13
Archiving old bugs that haven't been actively assigned in over 180 days. If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks! |
|||||||||||||||
►
Sign in to add a comment |
|||||||||||||||
Comment 1 by sdy@google.com
, Jun 19 2016