Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

Crashing main process is losing window state #10349

Closed
bbondy opened this issue Aug 9, 2017 · 5 comments
Closed

Crashing main process is losing window state #10349

bbondy opened this issue Aug 9, 2017 · 5 comments

Comments

@bbondy
Copy link
Member

bbondy commented Aug 9, 2017

  • Did you search for similar issues before submitting this one?
    Yes.

  • Describe the issue you encountered:
    Using debug menu

  • Platform (Win7, 8, 10? macOS? Linux distro?):
    macOS, probably others

  • Brave Version (revision SHA):
    0.18.x through master

  • Steps to reproduce:
    0. Clean session store (or not is fine)

    1. Open Brave and open a few tabs
    2. Quit normally
    3. Startup normally, and see tabs restored.
    4. BRAVE_ENABLE_DEBUG_MENU=1 open -a Brave
    5. Select crash main process
    6. Start Brave
  • Actual result:
    Tabs aren't restored.

  • Expected result:
    Tabs are restored.

  • Will the steps above reproduce in a fresh profile? If not what other info can be added?
    yes

  • Is this an issue in the currently released version?
    Yes

  • Can this issue be consistently reproduced?
    Yes

@bbondy bbondy added this to the 0.18.x Hotfix milestone Aug 9, 2017
@bbondy bbondy self-assigned this Aug 9, 2017
@luixxiul luixxiul added the bug label Aug 9, 2017
@bsclifton
Copy link
Member

Just for reference: original fix was delivered with #9912

bbondy added a commit that referenced this issue Aug 10, 2017
Fix #10349

Auditors: @bsclifton

This happens because a save would happen on init before the initial window state was present
bbondy added a commit that referenced this issue Aug 10, 2017
Fix #10349

Auditors: @bsclifton

This happens because a save would happen on init before the initial window state was present
bbondy added a commit that referenced this issue Aug 10, 2017
Fix #10349

Auditors: @bsclifton

This happens because a save would happen on init before the initial window state was present
bbondy added a commit that referenced this issue Aug 10, 2017
Fix #10349

Auditors: @bsclifton

This happens because a save would happen on init before the initial window state was present
@bbondy
Copy link
Member Author

bbondy commented Aug 10, 2017

0.18.x: 1dfd76e
0.19.x: b8296c1
0.20.x: f9d09f3
master: 2634bbf

@LaurenWags
Copy link
Member

Losing window state on MacOS

10349

@bbondy
Copy link
Member Author

bbondy commented Aug 11, 2017

I think this is actually fixed and it's just an issue with the way it's being tested.

Could you confirm @LaurenWags ?

open -a Brave.app will always open Brave.app in /Applications even if you are in a directory that has a different Brave.app.
I think open ./Brave.app would open the one in the local directory.

I'm thinking each time the right build is started, until you use the command line in the video. Then it uses the wrong one.

Marking as closed for retesting.

@LaurenWags
Copy link
Member

Used suggestion from @bbondy for testing and window state was preserved.

dfperry5 pushed a commit to dfperry5/browser-laptop that referenced this issue Aug 18, 2017
Fix brave#10349

Auditors: @bsclifton

This happens because a save would happen on init before the initial window state was present
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.