464110 - Toolbar Customization dialog only opens once per session

Status: RESOLVED FIXED

(Penelope Graveyard :: General, defect)

Description

[Matt Dudziak]

The problem is that the toolbar customization dialog only opens once per session. The secon and subsequent attempts to open the dialog result in an outline of the window briefly displaying then disappearing.

To reproduce:
- Launch Eudora 8.0.0b4 on Mac OS X
- Right click toolbar and select Customize
- click OK
- right click toolbar and select Customize
- Note Dialog flashes on screen then goes away
- Repeat and see same behavior
- Quite/restart Eudora and dialog will display

Comment 2

[Adil Allawi]

Attachment: Patch to let toolbar open more than once

Comment 3

[Adil Allawi]

Comment on attachment 347966 [details] [diff] [review]
Patch to let toolbar open more than once

In Thunderbird 3 toolbar customisation opens as a sheet which behaves differently to dialog windows. The TB code want to open a XUL file called customizeToolbar.xul but does not find it. Patch works by adding this file.

As there is no obvious cancel button in sheets I also added 'restore defaults' feature from the original TB 3 customization sheet.

Comment 4

[Adil Allawi]

Sorry meant "customizeToolbarSheet.xul" instead of "customizeToolbar.xul" in above comment.

Comment 5

[Adil Allawi]

I looked further into this issue 

- here is what happens:

Window management on Windows/Linux is fundamentally different to the Mac. Look at mail/content/base/mailCore.js function: CustomizeMailToolbar(). What it is doing is platform dependent. On Windows/Linux it opens a dialog window. On the Mac it creates a panel that embeds an iFrame (an embedded window) and inserts the customize toolbar dialog in there. I guess that, drag/drop tool customization into a separate window will not work on a Mac.

Now Penelope replaces the Thunderbird customizeToolbar.xul with its own one that is a Dialog. mailCore.js is loading that Dialog into an iFrame. First time it is OK. But when you close and open again, XUL barfs. Which is not surprising as I do not think that Dialogs were really designed to by embedded into an iFrame.

How to fix this:

ideally we want to have one Penelope plug-in that is identical on all platforms. However, this looks like one of those cases that shows this may not be possible as Mac has a different way to manage windows than other platforms.

So we can do one of 2 things:

1/ Make the Penelope installer have platform-specific directories and do the right thing for each platform.

2/ Rewrite Penelope code to always use the Mac method of embedding customizeToolbar.xul into an iFrame which should also work.

My instinct says to vote for 1/ as ultimately we cannot have identical UI on Mac and Windows.

Comment 6

[Jeff Beckley]

For those with initiative, this bug is fixed in the Penelope hg source code
depot: <http://hg.mozilla.org/penelope/rev/0697adc97ca7>.

Otherwise you'll have to wait until the next release, Eudora 8 beta 5/Penelope
0.5a2.

There's now a file shared between Mac and non-Mac platforms that has the bulk of the UI elements in it: customizeToobarShared.xul.  The Mac (customizeToolbarSheet.xul) and non-Mac (customizeToolbar.xul) UI #includes that shared file so there's not a bunch of duplication.  The correct UI file is chosen using the "os" manifest flag in the jar.mn file, docs here: <https://developer.mozilla.org/en/Chrome_Registration#os>.

I added a number of other changes in the process:
- Added "Cancel" functionality on the Mac
- Made customizeToolbar.js look more like Thunderbird's to keep ours in sync with Thunderbird's and make diffs easier to track
- Added the Restore Default Set button
- Instead of #include'ing Thunderbird's customizeToolbar.dtd (which forced Penelope developers to have the Thunderbird source code to modify Penelope), just copy the few items that were needed out of it

Thanks to Adil for getting me thinking in the right direction for how to solve this.