(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #82783 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=82783 Imported into Bugzilla on 04/25/00 16:55) Using 4.02 dogbert builds for Win 3.1, Win95 and Unix dated after 8-14, the Title bar doesn't display the name of a mail msg correctly in these cases: A mail msg that has been signed with no attachments = no name A mail msg that has been signed with an attachment (view inline) = name of attachment A mail msg that has been signed with an attachment (view as link) = no name A mail msg that has not been signed with a .gif attachment (view inline) = name of .gif file For Unix, this causes a problem when bookmarking any of these messages. The name of the bookmark in the Bookmark list is the location of the mail msg in the case of no name. Or the name of the .gif in the case of viewing Inline. ------- Additional Comments From jfriend 08/21/97 17:13 ------- Since this only happens with signed messages, I assume this has something to do with the S/MIME code. ------- Additional Comments From trudelle 08/23/97 15:43 ------- Since this bug doesn't occur on Mac, the platform should not be 'ALL'. Since PC 4.0.2 is done, I'm changing the bug to platform X-TERM, although the fix should be checked into the trunk for PC 5.0 as well. This bug is still untargeted, please set the fix version. ------- Additional Comments From hong 03/03/98 17:21 ------- *** Bug 90109 has been marked as a duplicate of this bug. *** ------- Additional Comments From repka 04/29/98 15:08 ------- Jamie, do you have any idea why this happens? I can see it happening for me on 3.02 as well, though I never really noticed it before because I never look at the title bar in my mail or news windows. I'm really surprised that it happens on Win and Unix but not on Mac; I would have thought it'd be all the same backend problem. Anyway, I'd like the mail/news group to own this problem but it seems like that is unlikely. So I thought I'd see if I'd be able to fix it myself, perhaps with a pointer from you to get me started. ------- Additional Comments From scurtis 05/26/98 12:56 ------- I just noticed this bug in 4.06 and 4.5. Didn't all 5.0 mail/news bugs get migrated to tfv 4.5? Was this one overlooked? I just looked at 4.5 Mac, and the only reason it appears that the Mac is not affected is because it doesn't use the subject line info in its title bar, as Win and Unix do. I suggest either making this platform="all" again (since the 4.02 reasoning is now moot), or opening a separate and additional bug on Windows. ------- Additional Comments From scurtis 05/26/98 13:55 ------- Something interesting about this bug: If you send yourself a signed message with a web page attached (not just the URL included in an html message), the Messenger title bar will display the title of the attached web page. Also, going back to 4.04, when you click on a regular signed message, you can see the title bar flash what looks like an IMAP URL really fast before it fails to display the message subject. Changing severity from major to normal, since this is just an optionally-implemented display issue. ------- Additional Comments From repka 05/26/98 14:55 ------- Changing the platform back to All, as Stacey suggested. The problem is in the backend (libmime) -- it exists, at least in some sense, on all platforms. (It might even be that if you viewed an S/MIME message in a browser window -- does that have a real title bar, filled in by the <TITLE> tag, on the Mac? -- you would then see it on the Mac as well.) As for what tfv this bug should have, that confusion lies in the ownership of this bug. It's one of those limbo bugs, falling somewhere between security and mail/news. It's really not clear which of us *should* own it. I'd been thinking that if I could figure out how to fix it, I'd go ahead and do that. I would, in fact, prefer to fix it in 4.1, but I'm not sure I'll figure it out in time to do that. BTW, I know *why* it's happening, but I don't know what the fix should be. It happens because the display of each S/MIME message involves a table created for the headers (in order to put the "Signed", etc. icons over on the right of the headers). But when the <TITLE> tag is then output for the Subject line, our layout code ignores it because it doesn't allow a <TITLE> to be specified from within a table definition. (And when libmime parses subsequent stuff, like an attachment, if it puts out a <TITLE> later, that one will "take", which is why you see an attachment's Subject in the title.) I think the fix, then, is to somehow put the <TITLE> out either before or after the table of headers-and-icon are put out. Probably after is the only way that will really work. But I'm not sure that's the right solution, and even so I don't know where to do it (and how to find the subject text). That's where I am at the moment; I'm only working on this bug occasionally, in the background. (If someone from the mail/news group would be willing to take this bug and fix it in 4.5, I'd be quite happy to let go of it. ;-) ------- Additional Comments From phil 05/27/98 11:53 ------- Probably the best owner for this bug is jefft, so I'll reassign to him. Thanks for the legwork, Lisa. ------- Additional Comments From jfriend 08/31/98 13:16 ------- Major XP/IMAP Bug triage. TFV set to 4.5Later, resolution set to Later. ------- Additional Comments From jfriend 08/31/98 13:19 ------- Changing TFV 4.5Later bugs to Resolution LATER. ------- Additional Comments From marek Feb-23-2000 17:23 ------- Resolving all 4.5 bugs so far resolved as REMIND and LATER as WONTFIX.

Old bug just moved from internal to bugzilla. Reopening so I can reassign it and comment on it.

This is *not* an NSS bug. But to prevent it from getting lost forever, I am making it one and assigning it to Christian. He can close it if he wants, or play around with it. I don't even know how the mime->html stuff is done now, if it's different, and thus if this bug would occur in the new client when S/MIME is added (back) in. It's up to Christian if he wants to hang onto this for the future. It'd be okay with me if he wanted to close it out. I guess the real regression test, once S/MIME is working, is whether viewing email gets the right text in the Title bar, *and* whether bookmarking works (because apparantly that was the most annoying thing about this bug in the first place).

Confirming because of Bugsplat import. Gerv

This should be considered when S/MIME is integrated into Mozilla.

reassigning to ssu. Anyone have any ideas if this is working?

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420

This was already WFM with SeaMonkey 1.1.19.