Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

customization panel should not be open by default on New Tab page #5199

Closed
karenkliu opened this issue Jul 10, 2019 · 6 comments · Fixed by brave/brave-core#2814
Closed

customization panel should not be open by default on New Tab page #5199

karenkliu opened this issue Jul 10, 2019 · 6 comments · Fixed by brave/brave-core#2814

Comments

@karenkliu
Copy link

Description

Currently, the customization panel is open by default on New Tab page.
Screen Shot 2019-07-09 at 5 24 04 PM

Fix this so that the panel is not open by default.

@imptrx
Copy link

imptrx commented Jul 10, 2019

The first time someone opens NTP the settings menu would be off. I believe the current behavior you are experiencing is:

  • user visit NTP
  • the settings menu is turned on by the user
  • the user doesn't close it via clicking outside or button toggle

If that's the case, the menu would persist over to the next NTP session.
If we don't want to preserve the last session of the settings menu, that would be a different issue altogether, could we confirm if that's the case?

@rebron
Copy link
Collaborator

rebron commented Jul 10, 2019

@imptrx That's the case. Don't preserve the last session of the settings menu when user opens up a new tab page. Should always show closed when creating a new tab page.

@imptrx imptrx added this to the 0.69.x - Nightly milestone Jul 10, 2019
@imptrx
Copy link

imptrx commented Jul 10, 2019

Test Plan:

  1. Open new tabs page
  2. Open customization menu at the bottom right corner
  3. Open another NTP and assert customization menu is closed
  4. Close browser with customization menu open; NTP on a fresh browser instance should be closed

@petemill
Copy link
Member

@imptrx I suggest you use component state and not redux state for the openness of the menu, or just delete the redux property when the redux state is saved to localStorage

@imptrx
Copy link

imptrx commented Jul 10, 2019

@imptrx I suggest you use component state and not redux state for the openness of the menu, or just delete the redux property when the redux state is saved to localStorage

@petemill I currently have a "close menu" action attached to NTP component mount but I'll probably move that logic out of redux as you suggest 👍

@GeetaSarvadnya
Copy link

GeetaSarvadnya commented Aug 26, 2019

Verification passed on

Brave 0.69.115 Chromium: 76.0.3809.100 (Official Build) beta (64-bit)
Revision ed9d447d30203dc5069e540f05079e493fc1c132-refs/branch-heads/3809@{#990}
OS Windows 10 OS Version 1803 (Build 17134.523)

Verification passed on

Brave 0.69.116 Chromium: 76.0.3809.100 (Official Build) beta (64-bit)
Revision ed9d447d30203dc5069e540f05079e493fc1c132-refs/branch-heads/3809@{#990}
OS Ubuntu 18.04 LTS

Verification PASSED on macOS 10.14.6 x64 using the following build:

Brave 0.69.121 Chromium: 76.0.3809.132 (Official Build) beta (64-bit)
Revision fd1acc410994a7a68ac25bc77513d443f3130860-refs/branch-heads/3809@{#1035}
OS Mac OS X

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants