365755 - when only a compose window is open, I can't get back to the 3 pane

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[(not reading, please use [e-mail] instead)]

when only a compose window is open, I can't get back to the 3 pane

steps to reproduce:

1) open a compose window
2) close the 3 pane

I'm now unable to get back to the 3 pane.  maybe make double clicking on the tbird icon in the dock open a 3 pane when there isn't one?  (right now, double clicking on the tbird doc icon in this case does nothing.)

note, it's also not possible to get to the address book when in this state.

I'm using version 2 beta 1 (20061231) on mac os x 10.4.8

Comment 1

[(not reading, please use [e-mail] instead)]

s/double clicking/clicking

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

You don't have the entries "Mail & Newsgroups" and "Address Book" under the tool menu of your compose window? It works fine for Windows. If they are not available it should be a Mac OS only bug.

Comment 3

[(not reading, please use [e-mail] instead)]

> You don't have the entries "Mail & Newsgroups" and "Address Book" under the
tool menu of your compose window? 

no, I don't have those.  all I have is "Account Settings" under the "Tools" menu.

Comment 4

[Magnus Melin [:mkmelin]]

Seems mac only. My linux build does have the Mail & Newsgroups menu item.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Yeah it's only for Mac OS. David is this by design?

http://lxr.mozilla.org/seamonkey/source/mail/components/compose/content/messengercompose.xul#514

Comment 6

[David :Bienvenu]

I don't know why the mac menus are different - since the mac can have the app open without any windows open, I think it would be a priority to allow you to get to the three pane UI from the menu...

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Scott this was your checkin:

1.40 <[e-mail]> 2003-11-05 22:23
OSX only: add a Windows menu item to the mac build to keep track of all open windows. Thanks to Don Crandall for the patch!

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/mail/components/compose/content&command=DIFF_FRAMESET&file=messengercompose.xul&rev2=1.40&rev1=1.39

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Don could hopefully help us.

Comment 9

[(not reading, please use [e-mail] instead)]

the window menu keeps track of the open windows, right?

but in my case, I don't have a 3 pane window so it is not listed.

Comment 10

[Mike Cowperthwaite]

What about using the Cmd+1 shortcut -- does that work for Mac?

Comment 11

[(not reading, please use [e-mail] instead)]

> What about using the Cmd+1 shortcut -- does that work for Mac?

yes, that works for me on the mac!

Comment 12

[Scott MacGregor]

I believe this was caused by Bug 353588 where we started leveraging some toolkit code. Phil might be able to untangle this on the Mac. He likes these type of bugs :).

Comment 13

[Phil Ringnalda (:philor)]

Attachment: Fix v.1

You know the scene in Grosse Pointe Blank where Minnie Driver is saying "What is this I'm feeling?"? Picture her saying "What is this I'm feeling about this bug? Is it 'like'?" :)

This isn't quite entirely as pretty as I hope it will be by the time we ship 3.0, but it's branchable (thus the funkiness of overlaying key_addressbook, since otherwise I can't get it into addressbook.xul, where we don't have a copy of the lightly-localized string "2"), and it gives us Mac-proper static items in the Window menu for singleton windows (even while in that window - it's proper, not sensible).

Comment 14

[Scott MacGregor]

Comment on attachment 263099 [details] [diff] [review]
Fix v.1

Thanks Phil. I haven't hooked up my Mac yet since we moved into a new office so I haven't tested this patch out myself. Also, does this work for the stand alone message window as well? I think it should since mailWindowOverlay.xul effects the 3-pane and the stand alone but it's always good to double check.

Comment 15

[David :Bienvenu]

this patch works fine for me with my 2.0 build (it doesn't apply cleanly in mailWindowOverlay.xul, for some reason, but it's easy to apply by hand.)

Comment 16

[Scott MacGregor]

Comment on attachment 263099 [details] [diff] [review]
Fix v.1

bienvenu tested Phil's patch against the branch to make sure it looked ok there too before I asked for approval.

This effects tbird only and fixes a pretty significant usability issue between 1.5.0.x and 2.0

Comment 17

[Daniel Veditz [:dveditz]]

Comment on attachment 263099 [details] [diff] [review]
Fix v.1

approved for 1.8.1.4, a=dveditz

Comment 18

[David :Bienvenu]

fix landed on 1.8.1 branch. Thx, Phil!

Comment 19

[Phil Ringnalda (:philor)]

Thanks for covering for me - I was updating my 1.8 tree, hoping to see the string of "M"s that would say I'd already ported it and wouldn't have to just hope I got it right at the deadline, and it took me a few seconds to figure out what on earth a string of "U"s instead might mean :)

Trunk:
mail/base/jar.mn 1.100
mail/base/content/macMenuOverlay.xul 1.2
mail/base/content/mailWindowOverlay.xul 1.204
mail/components/addrbook/content/addressbook.xul 1.69
mail/components/compose/content/messengercompose.xul 1.101

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Great improvement. Works fine with version 2.0.0.4pre (20070430).

Comment 21

[(not reading, please use [e-mail] instead)]

marcia points this out:

after this change, on mac now, the "Address Book" menu item is now under the "Window" menu (along with the "Mail & Newsgroups" item), where as it used to be under Tools.

Note, it is there for the 3 pane, stand alone msg window, and the compose window.

Marcia wanted to double check that the move from "Tools" to "Window" was desired.

Comment 22

[Phil Ringnalda (:philor)]

Yep, intentional. In 1.5, we had the non-Mac-like AB menu item in the 3-pane's Tools menu, without a parallel 3-pane menu item in the AB's Tools menu, plus the two items in the Window menu that are (roughly, since neither one is a utility window, strictly speaking) Mac-like; in 2.0.0.0 we lost the right ones while hanging onto the wrong one; in 2.0.0.4 we get the right ones back and lose the wrong one. 

Comment 23

[Axel Hecht [:Pike]]

Reopening, this broke at least German, probably Danish, too, on the 1.8 branch. Bug 380725 was filed for the German testing.

The culprit is that macMenuOverlay.xul imports chrome://messenger/locale/messenger.dtd without having brand.dtd first. Many strings in messenger.dtd assume that brand.dtd stuff is there, so do the German and Danish values for messengerCmd.label, and thus lead to xul parsing errors.

Expat seems to be clever and not bust on missing entities in unused strings, which is why that works in en-US, apparently.

The right fix is to pull in brand.dtd in macMenuOverlay.xul before messenger.dtd, at least I'm confident it is.

Note to drivers, reusing existing strings is l10n impact and needs testing.

Comment 24

[Alex Ihrig [:Thunderbird_Mail_DE]]

(In reply to comment #23)
> The culprit is that macMenuOverlay.xul imports
> chrome://messenger/locale/messenger.dtd without having brand.dtd first. Many
> strings in messenger.dtd assume that brand.dtd stuff is there, so do the German
> and Danish values for messengerCmd.label, and thus lead to xul parsing errors.

Because of green l10n-tinderboxen in this case, l10n teams aren't aware of the resulting XUL error.

Comment 25

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Attachment: Follow-up fix for l10n bustage

This patch needs testing on each platform and different locales.

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Comment on attachment 264869 [details] [diff] [review]
Follow-up fix for l10n bustage

Patch tested with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.4pre) Gecko/20070515 Thunderbird/2.0.0.4pre ID:2007051503

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; da; rv:1.8.1.4pre) Gecko/20070515 Thunderbird/2.0.0.4pre ID:2007051503

Before applying the patch I can see the red warning in both builds. After I patched macMenuOverlay.xul both builds doesn't show this error anymore.

Couldn't test l10n a trunk nighly because it doesn't start here. Dunno why.

Comment 27

[Daniel Veditz [:dveditz]]

This blocks Thunderbird 2.0.0.4

Comment 28

[Phil Ringnalda (:philor)]

Comment on attachment 264869 [details] [diff] [review]
Follow-up fix for l10n bustage

Bleah. r=philringnalda based on it being the obviously right way to fix my screwup, and based on it still working fine in en-US, but I'm not well pleased by XUL. Guess I better learn how to pull and build every locale, if the only way to test l10n is by visual examination.

Comment 29

[Scott MacGregor]

Comment on attachment 264869 [details] [diff] [review]
Follow-up fix for l10n bustage

We'd like to land this on the 1.8 branch and then re-tag this one file for Thunderbird since we haven't started making 2.0.0.4 builds for tbird yet.

Comment 30

[Phil Ringnalda (:philor)]

Trunk: macMenuOverlay.xul 1.3

Thanks for fixing my screwup, Henrik.

Comment 32

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Fixed on trunk but not for 1.8.1.4 => Version: Trunk

Comment 33

[Daniel Veditz [:dveditz]]

Comment on attachment 264869 [details] [diff] [review]
Follow-up fix for l10n bustage

approved for 1.8.1.4, a=dveditz

Comment 34

[Phil Ringnalda (:philor)]

mail/base/content/macMenuOverlay.xul 1.1.2.2

Comment 35

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.4pre) Gecko/20070518 Thunderbird/2.0.0.4pre ID:2007051803

I'm not able to test with a trunk builds because they don't work currently.