Closed Bug 365755 Opened 18 years ago Closed 17 years ago

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

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: moco, Assigned: philor)

References

Details

(Keywords: verified1.8.1.4)

Attachments

(2 files)

Fix v.1
9.60 KB, patch
mscott
: review+
dveditz
: approval1.8.1.4+
Details | Diff | Splinter Review
Follow-up fix for l10n bustage
818 bytes, patch
philor
: review+
mscott
: superreview+
dveditz
: approval1.8.1.4+
Details | Diff | Splinter Review 
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
s/double clicking/clicking
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.
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 <scott@scott-macgregor.org> 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 :).
Blocks: 353588
Assignee: mscott → philringnalda
Blocks: 378635
Attached patch Fix v.1 — — Splinter Review 
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).
Attachment #263099 - Flags: review?(mscott)
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.
Attachment #263099 - Flags: review?(mscott) → review+
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
Attachment #263099 - Flags: approval1.8.1.4?
Comment on attachment 263099 [details] [diff] [review]
Fix v.1

approved for 1.8.1.4, a=dveditz
Attachment #263099 - Flags: approval1.8.1.4? → approval1.8.1.4+
fix landed on 1.8.1 branch. Thx, Phil!
Keywords: fixed1.8.1.4
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
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Great improvement. Works fine with version 2.0.0.4pre (20070430).
Keywords: fixed1.8.1.4 → verified1.8.1.4
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 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. 
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.
Status: RESOLVED → REOPENED
Keywords: verified1.8.1.4
Resolution: FIXED → ---
(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.
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: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.
Attachment #264869 - Flags: review?(mscott)
Flags: blocking1.8.1.4?
Attachment #264869 - Flags: superreview?(mscott)
Attachment #264869 - Flags: review?(philringnalda)
Attachment #264869 - Flags: review?(mscott)
This blocks Thunderbird 2.0.0.4
Flags: blocking1.8.1.4?
Flags: blocking1.8.1.4+
Flags: blocking-thunderbird2?
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.
Attachment #264869 - Flags: review?(philringnalda) → review+
Attachment #264869 - Flags: superreview?(mscott) → superreview+
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.
Attachment #264869 - Flags: approval1.8.1.5?
Trunk: macMenuOverlay.xul 1.3

Thanks for fixing my screwup, Henrik.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Flags: blocking-thunderbird2? → blocking-thunderbird2+
Fixed on trunk but not for 1.8.1.4 => Version: Trunk
Version: 2.0 → Trunk
Comment on attachment 264869 [details] [diff] [review]
Follow-up fix for l10n bustage

approved for 1.8.1.4, a=dveditz
Attachment #264869 - Flags: approval1.8.1.5? → approval1.8.1.4+
mail/base/content/macMenuOverlay.xul 1.1.2.2
Keywords: fixed1.8.1.4
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.
Keywords: fixed1.8.1.4 → verified1.8.1.4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: