1922777 - Sidebar would not remember last used panel

Status: VERIFIED FIXED

(Firefox :: Sidebar, defect, P1)

Description

[Alice0775 White]

Steps to reproduce:

1. Open Firefox with new profile
2. Put Sidebars toolbutton on Nav bar from Customize toolbar
3. Click the Sidebars toolbutton
4. Change sidebar panel from sidebar header to History from Bookmarks.
5. Close the Sidebar
   --- So, last used sidebar is History
6. Close the browser
7. Re-open the browser with the same profile of step 1
8. Click the Sidebars toolbutton

Actual results:
Sidebar opens Bookmarks panel

Expected results:
Sidebar should open last used panel. In this case History panel

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=26e8012d5da938871783505e3753b681ab8cb186&tochange=e86e777fced482506de767727a313be25003c673

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:nsharpley, since you are the author of the regressor, bug 1885894, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[:Gijs (he/him)]

I think this is a dupe of bug 1908019, right?

Comment 3

[Alice0775 White]

(In reply to :Gijs (he/him) from comment #2)

I think this is a dupe of bug 1908019, right?

I do not think this is duplication.
Because, It reproduced with newly created profile and I am not using "Clear Recent History" and any related settings.

Comment 4

[Nikki Sharpley (:nikkis) (she/her)]

Not a duplication, but I think a bug 1908019 patch would solve it. I've picked that up from :sclements, so in progress.

Comment 5

[Mathew Hodson]

Was this fixed by bug 1908019?

Comment 6

[Alice0775 White]

(In reply to Mathew Hodson from comment #5)

Was this fixed by bug 1908019?

I can still reproduce this on Nightly134.0a1(20241029155057) Windows11.

Comment 7

[Sarah Clements [:sclements]]

(In reply to Mathew Hodson from comment #5)

Was this fixed by bug 1908019?

No, that bug was for a different issue altogether.

Comment 9

[Alice0775 White]

Not duplicate. Because of sidebar.revamp is false (default) in this bug.

Comment 10

[Sarah Clements [:sclements]]

(In reply to Alice0775 White from comment #9)

Not duplicate. Because of sidebar.revamp is false (default) in this bug.

It's being treated as a duplicate because of how sidebar state properties are now stored - which is entirely in session restore - so it doesn't matter practically whether a user is using the new or old sidebar the fix is the same (and since it is caused by the work in bug 1892033, which the duped bug was also regressed by).

Comment 11

[Alice0775 White]

This is not fixed yet. I can reproduce the issue on Nightlt140.0a1 139.0b7 138.0.2 as well as esr128.10.

Comment 12

[Sarah Clements [:sclements]]

Can you give some context on why this was reopened please?

Comment 13

[Alice0775 White]

(In reply to Sarah Clements [:sclements] from comment #12)

Can you give some context on why this was reopened please?

Bug 1921536 did not fix the issue from STR of comment#0.
I can still reproduce the issue on Nightlt140.0a1 139.0b7 138.0.2 as well as esr128.10.

Thanks

Comment 17

[Alexey71]

Starting from version 127, the panel is broken
Last working version 126.0.1
Firefox 126.0.1 https://youtu.be/3q8It2O97pQ
Firefox 139.0.1+ https://youtu.be/-30dTH3VVqk

Comment 18

[Alexey71]

Any news on the fix? It's starting to get annoying.

Comment 20

[:Gijs (he/him)]

(In reply to Alexey71 from comment #18)

Any news on the fix? It's starting to get annoying.

Not as yet. Have you considered enabling the new sidebar via the Firefox settings ("Show sidebar")? If that doesn't work for you, can you share more on why?

Comment 21

[Alexey71]

(In reply to :Gijs (he/him) from comment #20)

(In reply to Alexey71 from comment #18)

Any news on the fix? It's starting to get annoying.

Not as yet. Have you considered enabling the new sidebar via the Firefox settings ("Show sidebar")? If that doesn't work for you, can you share more on why?

The new side panel also does not remember the last state. It also does not remember the sorting selection. After restarting, you have to select everything again. I need quick access with one click to the complete history sorted by last visit. Everything was fine until Firefox version 127 ((

Comment 22

[Sarah Clements [:sclements]]

(In reply to Alexey71 from comment #21)

(In reply to :Gijs (he/him) from comment #20)

(In reply to Alexey71 from comment #18)

Any news on the fix? It's starting to get annoying.

Not as yet. Have you considered enabling the new sidebar via the Firefox settings ("Show sidebar")? If that doesn't work for you, can you share more on why?

The new side panel also does not remember the last state. It also does not remember the sorting selection. After restarting, you have to select everything again. I need quick access with one click to the complete history sorted by last visit. Everything was fine until Firefox version 127 ((

Thanks for flagging this - we've captured this separately in bug 1972168.

Comment 23

[animeyu]

Anyone know when this problem will be fixed?

Comment 24

[animeyu]

Why was my comment tagged as advocacy?

Comment 25

[Sam Foster [:sfoster] (he/him)]

I'm not able to reproduce this. And I've tried going back to 138 with mozregression and still no luck. Here's what I'm doing:

• Create a new profile, enable "Open previous windows and tabs"
• Open the (legacy, not revamp) history sidebar (ctrl + H)
• Quit the browser

At this point I can confirm that the window data saved in sessionstore.jsonlz4 has an entry for sidebar like { "command": "viewHistorySidebar" }. When I restart the browser, the sidebar re-opens with the history panel as expected. Then, I use mozregression with this profile:

./mach mozregression --find-fix --bad 138 --profile '/path/to/saved/history-sidebar-profile' --profile-persistence=clone-first

The browser opens and the sidebar is already open with the history panel. And I'm unable to find a version where this is not the case - so I guess I'm missing a step or condition? If the sidebar state was simply not being saved, we'd expect the sidebar to just be closed, not open at the bookmarks panel.

If this still reproduces for you with a clean profile, can you attach the sessionstore.jsonlz4 that is saved after you quit the browser? (this has tab urls and history etc in it, so please only share this from clean profile where you've just enabled session restore and opened the history sidebar). Anything else I'm missing?

Comment 26

[Alice0775 White]

Your STR is unrelated to this bug.

Before Quit the browser, you should close the sidebar.
Then relaunch browser and open sidebar from the legacy sidebar toolbar button.

I can still reproduce the issue with STR of comment#0 on Nightly141.0a1 Windows11.

Comment 27

[Alberto Salvia Novella]

@Sam Foster

Can you reproduce the issue like this?:
https://youtu.be/8urykue_fow

Comment 28

[Alexey71]

Attachment: 126sessionstore.jsonlz4

sessionstore.jsonlz4 from version 126.0.1, where it works fine

Comment 29

[Alexey71]

Attachment: 127sessionstore.jsonlz4

sessionstore.jsonlz4 from version 127.0. Starting with this version, there is a bug.

Comment 30

[Sam Foster [:sfoster] (he/him)]

Ok thanks both of you. This looks to have been intentional, there's even a comment explaining that we'll choose not to remember last-used sidebars when the panel is closed. I'm looking through notes from that bug and I don't see where this requirement came from - I'll need to confirm which is the behavior we want.

Comment 31

[Sam Foster [:sfoster] (he/him)]

Attachment: Bug 1922777 - Retain the last-used sidebar view/command id even when the panel is closed. r=#sidebar-reviewers

Comment 32

[Sam Foster [:sfoster] (he/him)]

[Tracking Requested - why for this release]: Regression from 128. This turned out to be a trivial fix.

Comment 33

[Alberto Salvia Novella]

@Sam Foster

What do you mean?

Comment 34

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox141 (nightly). However, the bug still has low priority and has low severity.

:pluk, could you please increase the priority and increase the severity for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 35

[Sam Foster [:sfoster] (he/him)]

I plan to land this after the merge and consider an uplift at that point.

Comment 36

[Alberto Salvia Novella]

So much messaging for such a simple error.

Comment 37

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0653f923d96b
https://hg.mozilla.org/integration/autoland/rev/7392c3a13f8c
Retain the last-used sidebar view/command id even when the panel is closed. r=sidebar-reviewers,nsharpley

Comment 38

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/7392c3a13f8c

Comment 39

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:sfoster, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox141 to wontfix.

For more information, please visit BugBot documentation.

Comment 40

[Sam Foster [:sfoster] (he/him)]

Attachment: Bug 1922777 - Retain the last-used sidebar view/command id even when the panel is closed. r=#sidebar-reviewers

Original Revision: https://phabricator.services.mozilla.com/D254261

Comment 41

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: See https://bugzilla.mozilla.org/show_bug.cgi?id=1922777#c0
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: See https://bugzilla.mozilla.org/show_bug.cgi?id=1922777#c0
• Risk associated with taking this patch: Low
• Explanation of risk level: Well bounded patch, very simple front-end patch. It removes code that explicitly prevented remembering and storing the last-used panel
• String changes made/needed: None
• Is Android affected?: no

Comment 42

[Sam Foster [:sfoster] (he/him)]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #39)

The patch landed in nightly and beta is affected.
:sfoster, is this bug important enough to require an uplift?

I think this would be low-risk to uplift.

Comment 43

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/24500bb428d4
https://hg.mozilla.org/releases/mozilla-beta/rev/3ffb72674f0c

Comment 44

[Ryan VanderMeulen [:RyanVM]]

Do we want this on ESR140 also?

Comment 45

[Sam Foster [:sfoster] (he/him)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #44)

Do we want this on ESR140 also?

If possible, yes I don't think it would hurt. Do I need a new patch for that, or can I just ask lando uplift attachment 9497737 [details]?

Comment 46

[Ryan VanderMeulen [:RyanVM]]

The patch appears to cherry-pick cleanly, so a Lando request should suffice.

Comment 47

[Sam Foster [:sfoster] (he/him)]

Attachment: Bug 1922777 - Retain the last-used sidebar view/command id even when the panel is closed. r=#sidebar-reviewers

Original Revision: https://phabricator.services.mozilla.com/D254261

Comment 48

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: See https://bugzilla.mozilla.org/show_bug.cgi?id=1922777#c0
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: See https://bugzilla.mozilla.org/show_bug.cgi?id=1922777#c0
• Risk associated with taking this patch: Low
• Explanation of risk level: Well bounded patch, very simple front-end patch. It removes code that explicitly prevented remembering and storing the last-used panel
• String changes made/needed: None
• Is Android affected?: no

Comment 49

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/1fe2f1d959a6

Comment 50

[Monica Chiorean]

I was able to reproduce the issue on Win11x64 using Firefox build 133.0a1(20241004205955).
Verified as fixed on Win11x64 using Firefox builds 140.1.0esr / 141.0 / 142.0a1.