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

Restore sidebar state when resizing a window #5586

Closed
jasmussen opened this issue Mar 13, 2018 · 4 comments · Fixed by #5978
Closed

Restore sidebar state when resizing a window #5586

jasmussen opened this issue Mar 13, 2018 · 4 comments · Fixed by #5978
Assignees
Labels
[Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@jasmussen
Copy link
Contributor

This appears to be a regression per the merge of the in-progress sidebar API.

If you have the sidebar toggled, then resize the window to be small, the sidebar is untoggled. This is in contrast to the previous behavior, where the sidebar state was not untoggled, the editor just entred into a mobile state, where the sidebar is a modal.

The problem is, that the sidebar should be enabled by default on a vanilla out-of-the-box WordPress install. This is key in order for users to learn that if you dismiss the sidebar by pressing the X in the top right corner of the sidebar, you can see that the cog icon is untoggled in the editor bar. This teaches users how to get the sidebar back (and we can show a pointer as well). If a user simply resizes the viewport and it disappears, this connection is less likely to happen.

restore sidebar state on resize

Ideally the sidebar would be restored when you return to the desktop breakpoint, unless you explicitly toggle it off.

@jasmussen jasmussen added [Type] Bug An existing feature does not function as intended Design labels Mar 13, 2018
@jasmussen
Copy link
Contributor Author

CC: @atimmer @IreneStr I believe you worked on the sidebar API.

@jorgefilipecosta jorgefilipecosta self-assigned this Mar 13, 2018
@jorgefilipecosta
Copy link
Member

jorgefilipecosta commented Mar 13, 2018

As part of PR #5435, we discussed a possible improvement to the state logic that would allow the recovering of this behavior: #5435 (comment)
At the time of that refactoring, it was better not to add this logic right away as it would make the PR huge.
I can try to submit a PR that follows the logic discussed. Of course, if another person is interested in working on this feel free to comment.

@jasmussen
Copy link
Contributor Author

At the time of that refactoring, it was better not to add this logic right away as it would make the PR huge.

It's totally okay to make tradeoffs like that when shipping new features, just wanted to make sure this was tracked so it doesn't fall between the cracks.

I can try to submit a PR that follows the logic discussed. Of course, if another person is interested in working on this feel free to comment.

Not super urgent, but definitely something the final version should have.

@IreneStr
Copy link
Member

It was indeed a known issue in the initial sidebar PR. I believe @jorgefilipecosta also had some ideas about simplifying the state tree that should make handling this/storing the active sidebar much easier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants