963494 - 'Restore defaults' does not restore the appearance of the default toolbar buttons when they were placed in the menu before

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[Peter Retzer (:pretzer)]

Attachment: Screenshot of the issue

STR:
1. Enter Customization Mode
2. Move the Bookmarks button, the Downloads button and/or the Home button to the menu
3. Hit 'Restore defaults' 

Actual result:
See the screenshot. The buttons are added to the toolbar with a label below or next to them

Expected result:
The buttons are added to the toolbar and their 'toolbar appearance is restored


Note: This doesn't happen if the buttons are moved to the palette instead of the menu.

Comment 1

[:Gijs (he/him)]

Attachment: Australis' customization reset doesn't reset wrap attribute,

Comment 2

[Mike de Boer [:mikedeboer]]

Comment on attachment 8364976 [details] [diff] [review]
Australis' customization reset doesn't reset wrap attribute,

Review of attachment 8364976 [details] [diff] [review]:
-----------------------------------------------------------------

You're setting the 'wrap' attribute in a couple of other places as well... in other words, does this also reset the wrap attribute when you move/ customize a widget from the menu-panel to the navbar, or do we need to add more of these checks?

Comment 3

[:Gijs (he/him)]

(In reply to Mike de Boer [:mikedeboer] from comment #2)
> Comment on attachment 8364976 [details] [diff] [review]
> Australis' customization reset doesn't reset wrap attribute,
> 
> Review of attachment 8364976 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> You're setting the 'wrap' attribute in a couple of other places as well...
> in other words, does this also reset the wrap attribute when you move/
> customize a widget from the menu-panel to the navbar, or do we need to add
> more of these checks?

removeWidgetFromArea removes the wrap attribute. That is always called if the user or code moves an item from one area to another - except if buildArea moves the widget itself. Hence the issue.

Comment 4

[:Gijs (he/him)]

Attachment: Australis' customization reset doesn't reset wrap attribute,

Alright, try this instead? Very astute observation. :-)

Comment 5

[Mike de Boer [:mikedeboer]]

Comment on attachment 8365008 [details] [diff] [review]
Australis' customization reset doesn't reset wrap attribute,

Review of attachment 8365008 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!

Comment 6

[:Gijs (he/him)]

remote:   https://hg.mozilla.org/integration/fx-team/rev/3977d57df656

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3977d57df656

Comment 10

[IU]

Attachment: daily_menu_bug2.png

This issue is not fully fixed.  It affects Daily too.  See attachment.

Still reproducible with Daily with cset: http://hg.mozilla.org/mozilla-central/rev/9e06d42c2a6a

Comment 11

[:Gijs (he/him)]

(In reply to IU from comment #10)
> Created attachment 8365539 [details]
> daily_menu_bug2.png
> 
> This issue is not fully fixed.  It affects Daily too.  See attachment.
> 
> Still reproducible with Daily with cset:
> http://hg.mozilla.org/mozilla-central/rev/9e06d42c2a6a

Can you please file a new bug with steps to reproduce based on an empty profile (without add-ons) and CC me? Thanks!

Comment 12

[Cornel Ionce [:noni] [Hubs QA]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Microsoft Surface Pro 2)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Mozilla/5.0 (X11; Linux i686; rv:29.0) Gecko/20100101 Firefox/29.0

The buttons are properly restored on Firefox 29 beta 1(build ID: 20140318013849) using a clean profile.