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

Focused window does not have focus when restarting #13158

Closed
petemill opened this issue Feb 16, 2018 · 2 comments · Fixed by #13161
Closed

Focused window does not have focus when restarting #13158

petemill opened this issue Feb 16, 2018 · 2 comments · Fixed by #13161
Assignees
Labels
initiative/reduce-bugs priority/P5 Cosmetic. Spelling, copy, layout. New features (which should also be part of an initiative). QA/test-plan-specified release/not-blocking release-notes/include stale

Comments

@petemill
Copy link
Member

petemill commented Feb 16, 2018

note: I noticed this, and made a fix, when testing Buffer Windows in #12438, but it is a regression from 0.20.x or before. Assigning to same milestone as buffer windows, but can be moved if the fix shouldn't land in that milestone.

Description

This is caused by two reasons:

  • An incorrect redux action name is preventing 'focusTime' from getting saved to windowState accurately
  • We now open windows asynchronously, so window's could render and be shown, at different times and not in the order the windows were asked to be created

Test plan / Steps to Reproduce

  1. Open several windows with tabs
  2. Place the windows at different coordinates with different sizes
  3. Focus the windows in a specific order
  4. Quit Brave
  5. Start Brave

Actual result:

  • The last-focused window does not always have focus.
  • The stacking order is not remembered.

Expected result:
The windows are layered in the same stacking order as they were previously. The last window to have focus, has focus after restart

@petemill petemill added this to the 0.21.x (Beta Channel) milestone Feb 16, 2018
@petemill petemill self-assigned this Feb 16, 2018
petemill added a commit that referenced this issue Feb 16, 2018
…dex is restored and the previously-focused window gets focus

Fix #13158
petemill added a commit that referenced this issue Feb 16, 2018
…dex is restored and the previously-focused window gets focus

Fix #13158
bsclifton pushed a commit that referenced this issue Feb 19, 2018
…dex is restored and the previously-focused window gets focus

Fix #13158
@LaurenWags
Copy link
Member

reproduced the stacking order not being remembered.

This is how the windows were when closing 0.21.11:
screen shot 2018-02-21 at 3 05 55 pm

This is how they were upon opening:
screen shot 2018-02-21 at 3 07 10 pm

@LaurenWags LaurenWags reopened this Feb 21, 2018
@petemill
Copy link
Member Author

This is a good candidate to be bumped to the next release to look at perfecting it, or moving to triage, since it works more of the time now (it will never be perfect as some timing is out of our control, though the above scenario should probably work)

ryanml pushed a commit to ryanml/browser-laptop that referenced this issue Feb 27, 2018
…dex is restored and the previously-focused window gets focus

Fix brave#13158
@alexwykoff alexwykoff added the priority/P5 Cosmetic. Spelling, copy, layout. New features (which should also be part of an initiative). label Feb 27, 2018
@alexwykoff alexwykoff modified the milestones: 0.22.x (Developer Channel), Backlog (Prioritized) Feb 27, 2018
@bsclifton bsclifton removed this from the Backlog (Prioritized) milestone Sep 3, 2018
@bsclifton bsclifton added the stale label Sep 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
initiative/reduce-bugs priority/P5 Cosmetic. Spelling, copy, layout. New features (which should also be part of an initiative). QA/test-plan-specified release/not-blocking release-notes/include stale
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants