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
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.
> 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.
Seems mac only. My linux build does have the Mail & Newsgroups menu item.
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
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...
Scott this was your checkin: 1.40 <email@example.com> 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
Don could hopefully help us.
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.
What about using the Cmd+1 shortcut -- does that work for Mac?
> What about using the Cmd+1 shortcut -- does that work for Mac? yes, that works for me on the mac!
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 :).
Created attachment 263099 [details] [diff] [review] 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 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.
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 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 on attachment 263099 [details] [diff] [review] Fix v.1 approved for 220.127.116.11, a=dveditz
fix landed on 1.8.1 branch. Thx, Phil!
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
Great improvement. Works fine with version 18.104.22.168pre (20070430).
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.
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 22.214.171.124 we lost the right ones while hanging onto the wrong one; in 126.96.36.199 we get the right ones back and lose the wrong one.
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.
(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.
Created attachment 264869 [details] [diff] [review] Follow-up fix for l10n bustage This patch needs testing on each platform and different locales.
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:188.8.131.52pre) Gecko/20070515 Thunderbird/184.108.40.206pre ID:2007051503 Mozilla/5.0 (Macintosh; U; Intel Mac OS X; da; rv:220.127.116.11pre) Gecko/20070515 Thunderbird/18.104.22.168pre 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.
This blocks Thunderbird 22.214.171.124
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 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 126.96.36.199 builds for tbird yet.
Trunk: macMenuOverlay.xul 1.3 Thanks for fixing my screwup, Henrik.
Fixed on trunk but not for 188.8.131.52 => Version: Trunk
Comment on attachment 264869 [details] [diff] [review] Follow-up fix for l10n bustage approved for 184.108.40.206, a=dveditz
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:220.127.116.11pre) Gecko/20070518 Thunderbird/18.104.22.168pre ID:2007051803 I'm not able to test with a trunk builds because they don't work currently.