User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Upgrade to 66.0.5. This is x64 flavour.
Language: PL
Windows 7
Let me know if you need more info.

Actual results:

The bookmarks toolbar dissapeared and cannot be restored with recommended solutions in the link below, do not work for the case:
https://support.mozilla.org/en-US/kb/recover-lost-or-missing-bookmarks#w_my-bookmarks-toolbar-is-missing

Expected results:

Bookmarks toolbar has to be available or possible to be enabled.

(In reply to thedarthkroolik from comment #0)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Upgrade to 66.0.5. This is x64 flavour.
Language: PL
Windows 7
Let me know if you need more info.

Actual results:

The bookmarks toolbar dissapeared and cannot be restored with recommended solutions in the link below:
https://support.mozilla.org/en-US/kb/recover-lost-or-missing-bookmarks#w_my-bookmarks-toolbar-is-missing

Expected results:

Bookmarks toolbar has to be available or possible to be enabled.

What is important: proper folder exists in bookmarks and all previous bookmarks exist there properly.

The priority flag is not set for this bug.
:mak, could you have a look please?

For more information, please visit auto_nag documentation.

Could you please check that you don't have a chrome/ folder in your profile folder (you can reach it from about:support). If so, move it out and see if the problem persists.
Another thing you can try is to run Places Database integrity check from about:support.

I'd also suggest to try to reset the toolbars to the default state, Right click on the toolbar, choose Customize and then Reset Defaults

1. there is not a chrome folder in the profile folder.
2. Database integrity executed - didn't resolve the issue.
3. Reset to defaults also didn't resolve the issue.
   In addition:
   After Firefox upgrade to 67.0.1 - the same procedure didn't help.

Could you please try removing the xulstore/ folder from the profile folder when Firefox is closed, and then starting it up again?

The problem is apparently due to sessionstore, if you remove both sessionstore.jsonlz4, and sessionstore-backups when Firefox is closed, it should solve.
Unfortunately by doing so you will lose the current session (open windows and tabs), if you care about that, you may want to store all the tabs in a bookmarks folder (right click on a tab, Select all the Tabs, Add tabs to bookmarks) and then reopen them in the new session.

Please let me know if this helps.

This is a sessionstore.jsonlz4 that should reproduce the problem, along with setting browser.startup.page == 3
I still don't know where the problem is, but the most relevant bits here is probably the property
"hidden": "menubar,personalbar"
It's possible we changed something in the way we restore these, and it ends up breaking the show/hide toggles, or the toggles work but we hide toolbars differently if this property is set?

So, the toolbars are hidden by this rule
https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/toolkit/content/xul.css#37

Through mozregression I found this range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a0c804993efc599a95e97bea39fa1528fd0195d8&tochange=5d73549d363f2a52854ff43fabac9c6fd05b90b0

To find this I created a profile with the above sessionstore and browser.startup.page == 3, then I tried on every build to flip on/off the bookmarks toolbar

(In reply to Marco Bonardo [::mak] from comment #12)

Through mozregression I found this range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a0c804993efc599a95e97bea39fa1528fd0195d8&tochange=5d73549d363f2a52854ff43fabac9c6fd05b90b0

To find this I created a profile with the above sessionstore and browser.startup.page == 3, then I tried on every build to flip on/off the bookmarks toolbar

bug 1034036 is the only bug in that window that touches browser/components/sessionstore.

Reviewing the changes for 'hidden', I noticed: https://hg.mozilla.org/mozilla-central/rev/6ce9efe2b20dbe3e625dcdf97ab0343f4f537475#l1.31

--- a/browser/components/sessionstore/SessionStore.jsm
+++ b/browser/components/sessionstore/SessionStore.jsm
@@ -686,23 +688,16 @@ var SessionStoreInternal = {
               state.windows[0].tabs[0].entries[0].url = "about:sessionrestore";
               state.windows[0].tabs[0].entries[0].triggeringPrincipal_base64 = Utils.SERIALIZED_SYSTEMPRINCIPAL;
             }
           }
 
           // Update the session start time using the restored session state.
           this._updateSessionStartTime(state);
 
-          // make sure that at least the first window doesn't have anything hidden
-          delete state.windows[0].hidden;
-          // Since nothing is hidden in the first window, it cannot be a popup
-          delete state.windows[0].isPopup;
-          // We don't want to minimize and then open a window at startup.
-          if (state.windows[0].sizemode == "minimized")
-            state.windows[0].sizemode = "normal";
           // clear any lastSessionWindowID attributes since those don't matter
           // during normal restore
           state.windows.forEach(function(aWindow) {
             delete aWindow.__lastSessionWindowID;
           });
         }
       } catch (ex) { debug("The session file is invalid: " + ex); }
     }

The removal of this failsafe explains why we can restore broken windows. I think we should restore it.

Of course, there is still the question of how we ever end up in this state, but even if we were fixing that we'd still need to reinstate the failsafe because it is self-evident from this bug that people have already ended up in this state.

(In reply to Marco Bonardo [::mak] from comment #7)

Could you please try removing the xulstore/ folder from the profile folder when Firefox is closed, and then starting it up again?

There is not such folder in Mozilla's Profile tree.

(In reply to thedarthkroolik from comment #15)

(In reply to Marco Bonardo [::mak] from comment #7)

Could you please try removing the xulstore/ folder from the profile folder when Firefox is closed, and then starting it up again?

There is not such folder in Mozilla's Profile tree.
BTW I'm already on 67.0.2 (64x).

Yes, we figured out the problem, see comment 8.

(In reply to Marco Bonardo [::mak] from comment #17)

Yes, we figured out the problem, see comment 8.

There are not such files available. The only with the extenstion .jsonlz4 are files for bookmarks and none for sessionstore.

Removing those .jsonlz4 which actualy exist in the mozilla's tree did not resolve the issue too.

(In reply to thedarthkroolik from comment #19)

Removing those .jsonlz4 which actualy exist in the mozilla's tree did not resolve the issue too.

Is there a xulstore.json file? If so, can you attach it to this bug?

(In reply to thedarthkroolik from comment #19)

Removing those .jsonlz4 which actualy exist in the mozilla's tree did not resolve the issue too.

Just to be sure, I assume you looked in the profile folder, not the Firefox install folder.

https://hg.mozilla.org/mozilla-central/rev/87aac9c06931

Comment on attachment 9070778 [details]
Bug 1551671 - don't allow restoring minimized or toolbarless initial windows, r?mikedeboer

Beta/Release Uplift Approval Request

• User impact if declined: Potentially able to open windows without certain UI (toolbars) present, with no user-accessible fix.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a belt-and-braces type fix where we ensure that the initial window opened by session restore is a fully functional browser window (and not, for example, a popup-style window with half the UI hidden with no way to get it back).
• String changes made/needed: no

Comment on attachment 9070778 [details]
Bug 1551671 - don't allow restoring minimized or toolbarless initial windows, r?mikedeboer

thanks, approved for 68.0b13

https://hg.mozilla.org/releases/mozilla-beta/rev/2737f084510e

1. There is not xulstore.json file in Mozilla tree, so nothing to be attached.
2. Yes, I'm searching profile tree, not the installation folder.

The problem is still not fixed.
Could simple removing current installation and reinstalling a new version help?
Or maybe should I switch to other kind of browser, like Chrome?

To be clear, the bug got resolved because a fix for this issue was landed in nightly. It's unrelated to your machine / 67.0.4 (at least, I hope you've updated your copy of release Firefox).

(In reply to thedarthkroolik from comment #27)

1. There is not xulstore.json file in Mozilla tree, so nothing to be attached.
2. Yes, I'm searching profile tree, not the installation folder.

This doesn't sound right. What files are directly in your profile folder?

Could simple removing current installation and reinstalling a new version help?

Unlikely.

I'm reporter of duplicate bug 1552253
I can confirm nightly 69.0a1 resolves my bug. But beta 68.0b12 does not.
In the nightly, I just needed to restore Personal Bar, with all the bookmarks safe. (Beware then, profile cannot be reverted to previous versions. So, please, backup if you need to).
Thank you.

(In reply to Tonin from comment #29)

But beta 68.0b12 does not.

This patch has landed in the beta repo but didn't make beta 12. It will be in the next beta release.

Hello,
I successfully reproduced the issue with Firefox 68.0a1 (20190516093926) on Windows 10 x64 using the following STR:

1. Open Firefox with a new profile containing user.js (user_pref("browser.startup.page", 3);)
2. Close Firefox and apply “sessionstore.jsonlz4” file from comment 9.
3. Open Firefox again and set Bookmarks Toolbar on/off.
   Thank’s Marco for the STR.

The only problem is that there is a different behavior on the latest Nightly and current beta. Following the above STR, I made a screen recording after Step 2 for 68.0b13 (20190624133534) and Nightly 69.0a1 (20190626215508). As can be seen in the video Nightly opens about:preferences page not “Test” page like beta, but the Bookmarks toolbar can be toggled on/off. Is this the expected behavior on Nightly?

The issue is verified fixed using 68.0b13 (20190624133534) on Windows10 x64, Ubuntu 18.04 and macOS 10.14. Waiting for confirmation for the behavior encountered on Nightly. Thank you!

(In reply to Alexandru Trif, QA [:atrif] from comment #31)

The only problem is that there is a different behavior on the latest Nightly and current beta. Following the above STR, I made a screen recording after Step 2 for 68.0b13 (20190624133534) and Nightly 69.0a1 (20190626215508). As can be seen in the video Nightly opens about:preferences page not “Test” page like beta, but the Bookmarks toolbar can be toggled on/off. Is this the expected behavior on Nightly?

Marco, is this an artifact of the sessionstore file you attached in some way?

(In reply to :Gijs (back Thursday; he/him) from comment #33)

Marco, is this an artifact of the sessionstore file you attached in some way?

Maybe? it was an hacked up sessionstore, cut from a much larger one. It should contain about:newTab (with a "Test" title) and about:preferences#home. Nightly seems to only restore the about:preferences page, while 67 and 68 open the about:newtab page. So, apparently things are restored slightly differently. I don't know why though, it's surely possible the data in the sessionstore is bogus enough to confuse the system. In the end its only scope was to reproduce this bug.
Maybe someone with deeper knowledge of the component can chime in.

I think we can call this verified for the purposes of this bug. If we're restoring the wrong tab in more cases, I'd expect to hear more about it in other bugs.

Hello!
Thank you for the verification. Removing the qe+ flag since no longer needed.

Resolved.
Works fine since update to 68.0 (x64).

(In reply to thedarthkroolik from comment #37)

Resolved.
Works fine since update to 68.0 (x64).

Thank you :)