Oana Botisan, Desktop QA Reporter
	Description • 6 years ago

[Affected versions]:
- Firefox 57.0.4
- beta 58.0b15
- latest Nightly 59.0a1

[Affected platforms]:
- Windows x64
- Mac OS x 10.11
- Ubuntu 16.04 x64

[Prerequisites]:
- Activate Bookmarks toolbar (right-click on tab toolbar and Bookmarks Toolbar)

[Steps to reproduce]:
1. Right-click on hamburger menu.
2. Click on Customize
3. Drag some items to Bookmarks Toolbar and click on "Done"
4. Deactivate Bookmarks Toolbar.
5. Enter "Customize" again. 

[Expected result]:
- Bookmarks Toolbar can be seen, because it has items that can be moved. 

[Actual result]:
- Bookmarks Toolbar and all the items placed there at step 3 are not visible. 

[Regression range]:
- In versions from 2013, on the Customize page the user could see and customize Bookmarks Toolbar even if wasn't activated. 

[Additional notes]:
- If the user deactivates the Bookmarks Toolbar and he had items in there, he can't find it only if he remembers that it's the space that he placed it. 
- A better idea would be if the user places anything on the Bookmarks Toolbar, after he is done with the Customize session, the Bookmarks Toolbar should be activated automatically.

	:Gijs (he/him)
	Comment 1 • 6 years ago

(In reply to Oana Botisan from comment #0)
> - In versions from 2013, on the Customize page the user could see and
> customize Bookmarks Toolbar even if wasn't activated. 

Which versions? We released australis in 2013. I'm pretty sure this behaviour has existed since then (version 29, so I would expect release (not nightly, because we landed australis on nightly a bit earlier) versions 28 and earlier to behave as you describe.

	Oana Botisan, Desktop QA Reporter
	Comment 2 • 6 years ago

(In reply to :Gijs from comment #1)

> Which versions? We released australis in 2013. I'm pretty sure this
> behaviour has existed since then (version 29, so I would expect release (not
> nightly, because we landed australis on nightly a bit earlier) versions 28
> and earlier to behave as you describe.

The last version I found that did that was Nightly 28.0a1 from 2013-11-17. I only checked the Nightly versions. 
In the version of Nightly 28.0a1 from 2013-11-18 already had austalis. 
I checked again and in Firefox 28.0 the Bookmarks Toolbar was still displayed.

	:Gijs (he/him)
	Comment 3 • 6 years ago

(In reply to Oana Botisan from comment #2)
> (In reply to :Gijs from comment #1)
> 
> > Which versions? We released australis in 2013. I'm pretty sure this
> > behaviour has existed since then (version 29, so I would expect release (not
> > nightly, because we landed australis on nightly a bit earlier) versions 28
> > and earlier to behave as you describe.
> 
> The last version I found that did that was Nightly 28.0a1 from 2013-11-17. I
> only checked the Nightly versions. 
> In the version of Nightly 28.0a1 from 2013-11-18 already had austalis. 
> I checked again and in Firefox 28.0 the Bookmarks Toolbar was still
> displayed.

Right, so this stopped being the case with Australis. I think that's intentional, because customize mode in australis makes it easy to hide/show toolbars. I think it would be confusing if the toolbar was visible in customize mode but then hid again when outside customize mode... Philipp/Aaron, can you confirm whether we want to do anything with the visibility of the toolbar in customize mode (either always or if/when it contains items) ?

	Aaron Benson
	Comment 4 • 6 years ago

Yeah, we should explore some ways to make the toolbar states more visible when customizing. I'm not totally against showing it all the time in customize mode but it would need more exploration to uncover any unforeseen conflicts.

For this particular issue, however, we'd discussed (waaaaaaay back almost a year ago during Photon planning) that the customize palette should be fixed and should contain all of the tools available to you in the browser. This means the icons in the palette are representations of the tools and not the "physical" tools themselves. This would prevent losing a tool that had been tucked away in a hidden corner of the UI (see also, 1388154).

	:Gijs (he/him)
	Comment 5 • 6 years ago

(In reply to Aaron Benson from comment #4)
> Yeah, we should explore some ways to make the toolbar states more visible
> when customizing. I'm not totally against showing it all the time in
> customize mode but it would need more exploration to uncover any unforeseen
> conflicts.
> 
> For this particular issue, however, we'd discussed (waaaaaaay back almost a
> year ago during Photon planning) that the customize palette should be fixed
> and should contain all of the tools available to you in the browser. This
> means the icons in the palette are representations of the tools and not the
> "physical" tools themselves. This would prevent losing a tool that had been
> tucked away in a hidden corner of the UI (see also, 1388154).

I think that (adaptations to customize mode) is the better solution. It's possible we can come up with more intuitive ways to hide/show the different toolbars by providing in-context buttons or whatever, but that should be a separate bug once there's a design. As it is, the work in bug 1388154 should/will address the main concern here:

(In reply to Oana Botisan from comment #0)
> If the user deactivates the Bookmarks Toolbar and he had items in there,
> he can't find it only if he remembers that it's the space that he placed it. 

In any case, I'm not super worried about people who manually activate/deactivate the bookmarks toolbar forgetting it exists. :-)