317424 - Customize dialog doesn't cancel icon size and mode when canceled

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Régis Caspar]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051120 Firefox/1.6a1
Build Identifier: Thunderbird version 1.5 (20051025)

When you customize toolbars, and change the apparence of toolbar button (Icon, Text, Text+Icon, use small icons, ...) and cancel the customization with the cancel button nothing is cancelled.

Reproducible: Always

Steps to Reproduce:
1. Right-click on a toolbar 
2. Choose "Customize..."
3. Check "Use Small Icons" (or change the drop down value (bottoom-left))
4. Toolbar icons become small
5. Press "Cancel"

Actual Results:  
Toolbar icons stay small as if ok was pressed.

Expected Results:  
Toolbar icons should be restored to previous state (here big icons)

Perhaps Thunderbird need like firefox only a "Done" button.

Comment 1

[Mike Cowperthwaite]

Reproduced with TB 1.5-1025, TB 1.6a1-1117, Win2K.

Comment 2

[Flummox]

Also present on Linux - version 2 alpha 1 (20060724)

Comment 3

[Mike Cowperthwaite]

Since the patch for bug 288079 (I think...) Cancel now doesn't seem to undo *any* changes -- any buttons you've dragged remain in their new positions on Cancel.  How about removing the Cancel button, and just let the user close the window via OK (or Close)?  Since the changes are all immediately visible and easily fixable by dragging again, I don't see a need to even implement a Cancel.

See bug 183419 -- the actual policy has never been set down in detail, but there is a desire to remove the single 'close' button from at least some types of windows.  The toolbar-customization dialog is an odd case -- it's not modal, but of necessity it is always on top.  Phil, if you're thinking the above is a good idea, you might ask Scott whether he'd prefer no buttons to an OK or Close in this case.

Comment 4

[Phil Ringnalda (:philor)]

Do you see anything in the error console, either when Cancel fails or critical things before it fails? At least in my Linux builds, I get an error from the shell service default client stuff in delayedOnLoadMessenger(), which means the customizedone handler doesn't get attached, which does rather bad things. If that's not it, then I need to fix it, since I don't see any way to interpret bug 358994 comment 1 as "please break it completely, and then remove it."

Comment 5

[Phil Ringnalda (:philor)]

(In reply to comment #4)
> Do you see anything in the error console

... like, for instance, a message saying "Error: Idiot allowed to break me."?

unwrapToolbarItems() removes the previousset attribute, which makes it rather hard for onCancel() to use it to reset the contents. Bug 288079 reopened. Sigh.

Comment 6

[Phil Ringnalda (:philor)]

Attachment: Fix v.1

Should be the last one before I start backporting to toolkit, and a good thing, since my test protocol's gotten so long I drift off in the middle of it.

I had to retract my "doesn't matter" about Cancel only canceling back to a Restore Default Set, since size and mode would restore back to the time you opened the dialog unless I actively broke them, so instead this makes Cancel set everything to how you opened the dialog, even if you did accidentally hit Restore Default Set (probably the most destructive thing in the dialog, and what you're most likely to want to cancel) at some point.

Comment 7

[Phil Ringnalda (:philor)]

Trunk: mail/base/content/customizeToolbar.js 1.12
Branch: mail/base/content/customizeToolbar.js 1.7.4.4

Comment 8

[Carsten Book [:Tomcat]]

verified fixed 1.8.1.3 using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 ID:2007032620 - the testcase is working fine for me, i can`t reproduce the bug report - adding the verified keyword