Mac (1999-10-26-08 M11) Summary: [PP]Regression: ??? marks in the buttons (View Complete Card and Add to Personal Addr. Book) Steps: 1. Send myself a message with vCard attachment 2 [details] [diff] [review]. View the Message in 5.0 Actual result: All I see is 3 question marks (??? ) in the two buttons Expected result: The two buttons should be View Complete Card and Add to Personal Address Book. This does not occur on win_nt 4.0 and Linux. It is a parity bug.

Reassign to Rich for investigation...

Hmm... sounds like our friend "the event queue" problem again. This could be since I'm sure the threading model for Mac is different than Win32 and Linux. I will investigate and reassign if it is the problem I believe it to be....but not before midnight. - rhp

Hi Erik, This is that problem we solved a while back with using string bundles from a non UI thread. libmime uses string bundles when creating the vCard and this is the problem we are seeing. - rhp

The StringBundle and Properties code is all XP. If there is a Mac-specific threading problem, it must be in the Necko or threading code. Re-assigning to Warren to check whether this is a Necko problem.

I think this has been fixed. Reopen if not.

Changing qa assigned to pmock@netscape.com

Re-opening bug. I can reproduce this problem in today Mac commercial seamonkey build. The symptoms are the same. ??? marks in the buttons (View Complete Card and Add to Personal Addr. Book). I see this problem under POP and IMAP viewing a HTML or plain text message with my attached 4.7 vcard. This problem does not occur on win32 and linux. The builds I tested were: ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/1999-12-06-09-M12/sea monkey32e.exe ftp://sweetlou/products/client/seamonkey/unix/linux_glibc/2.2/x86/1999-12-06-08- M12/netscape-i686-pc-linux-gnu.tar.gz ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/1999-12-06-08-M12/netscap e5-mac-M12.sea.bin

clearing resolution.

I'm trying to step through this on the mac, and what I think I'm seeing is that the wrong overloaded inline method is being called... This (from nsNetUtil.h): inline nsresult NS_OpenURI(nsIChannel* *result, nsIURI* uri, nsILoadGroup *aGroup, nsIInterfaceRequestor *capabilities = nsnull, nsLoadFlags loadAttributes = nsIChannel::LOAD_NORMAL, PRUint32 bufferSegmentSize = 0, PRUint32 bufferMaxSize = 0) instead of this: inline nsresult NS_OpenURI(nsIInputStream* *result, nsIURI* uri) I'm pretty sure the first one is being called, because I can step into the things it calls (although maybe the debugger is just skipping (really inlining) the first method. I've tried renaming the methods so that they're not overloaded, but had no luck.

Oh, forgot to add that what's really the problem (even if the second method really is being inlined but skipped by the debugger) is that the wrong result value is being returned (rv). I see the first method return NS_OK (0), but the call site gets what looks like a pointer. Seems like a compiler bug. Reassigning to sdagley for analysis.

targetting p3 for M13

scc is the man for compiler bugs. Reassigning after discussing it with him.

Triage: Marking M14 (thought I may get to it in M13).

Erik owns string bundle. Over to him.

Tao, do you have a Mac? If not, it might be better to assign it back to scc.

I don't have a Mac neither am Mac developer. Reassign to scc as suggested. However, this seems to be a dup of bug 26265 which had been fixed. I am marking this as fixed unless QA can reproduce it.

Mac (2000-03-09-09 M15)commercial I still this problem in today's Mac build. Re-open.

OK, thanks to fenella and grace's help, we verified that this is a different problem from 26265 which remains fixed. My speculation was wrong. Reassign to scc.

What do you want to bet the problem here is the calling convention of the function. As jband said ... be suspicious of anything that returns |nsresult| instead of saying |NS_METHOD| or the like.

It seems unlikely to me that the calling convention is the culprit unless this is being used as a callback; i.e. called via pointer to function. That doesn't seem to be the case. The compiler choosing the wrong method sounds likely, but renaming the things surely would fix that! Maybe the rebuild after the name change wasn't comprehensive enough? Calling the wrong method could certainly screwup the mechanism for returning the correct value. Is there are a call stack that can be attached to the report?

This bug really needs more investigation. Need some help setting the priority.

*** Bug 21288 has been marked as a duplicate of this bug. ***

This bug still reproducable on Mac build:2000-04-21-08-M16. I had a dup bug for this #30912

mass re-assigning to my new bugzilla account

fenella - does this still occur in the current build?

The problem is still reproducible on the mac build. I used the latest Mac commercial seamonkey build 2000-061216-m17 installed on G3/400 running MacOS 9.04. Under IMAP and POP, I still see the "???" for the button. When I expand the vcard, I see "???" in my vcard infront of all the contact phone numbers. This problem does not occur on Win32 commercial seamonkey build 2000-061209-m17 or linux commercial seamonkey build 2000-060908-m17.

I am getting *LOTS* of asserts when viewing a message with a vcard; can we please get this fixed soon? It blocks my daily use of mail so I'm adding keyword dogfood.

Putting on dogfood+ radar.

OK, what is the dogfood part? The asserts brade is seeing? Or the actual problem this bug is for, that the string bundle elements don't seem to be resolved on Mac. It sounds like the dogfood part is the asserts. Therefore, we need to know _what_ the asserts are. It would also be helpful to me if I could figure out how to make a vCard and attach it to my outgoing messages. Searching through the address book and preferences did not yield anything. Is this a commercial only feature? Fixing whatever assert is causing the trouble should be easy, once we can identify the assert. I have not been able to reproduce, since I can't make a vCard. Fixing the original problem may be much harder. A look back through the bug comments shows that everyone so far (including me) has been clueless, and as I can't reproduce at the moment, I don't think I can reasonably make an estimate for repair. If the urgent part is the asserts, let's get more information about that, and get it fixed right away --- asserts usually point right at the bad code. Kathy: stack trace? PDT: we can fix the assert immediately (upon arrival of a stack trace); does this meet your needs?

There are two asserts that happen in this situation. The first is caused by bad string accesses in the case of an empty string. This happens in the neighborhood of <http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimetpla.cpp#404> ...this is easily fixed, and unrelated to this bug. This assert fires only once but is easily fixed. I'll attach a patch soon. The second is at <http://lxr.mozilla.org/seamonkey/source/intl/strres/src/ nsStringBundle.cpp#129> and may be directly related to this bug. This assert fires repeatedly, and may be the key to solving this bug. It seems that the string bundle does not hold a valid reference to its persistent properties. Fix currently unknown, estimated time to fix unknown. If this is dogfood, wouldn't you want to set the milestone in a little bit? Say M17 maybe? OK PDT, where to from here? Is this really dogfood? When do you need a fix? Thanks leaf and akk for sending me vCards to discover this.

This bug might be better handled by someone who knows the rules for when a string bundle is allowed to have or not have a valid persistent properties reference. I see some routines that just exit out early with |if (!mProps) return;|, and then do an |NS_ENSURE_TRUE| on them. Others immediately use |NS_ENSURE_TRUE|, forcing an assert in debug builds where |mProps| is |0|. Which is right? Perhaps tao is the right person to understand and fix this assert? Should I re-assign?

Yes, the asserts were blocking folks from working - thus dogfood, please check in fix ASAP. thanks!

This latest patch I added, just above, fixed |GetStringByID| to be the same as the other functions like it in this file. This patch does not change the behavior of the program, as |NS_ENSURE_TRUE| exited the function immediately. I will check these two patches in as soon as the tree opens. That will fix the dogfood+ part of this bug. As to why |mProps| is null, I'll assign this bug to tao to investigate. Since tao has little Mac experience, it will absolutely require two people to fix: tao with his domain specific knowledge of string bundles, and a Mac person to spot the difference between Mac and XP behavior. Summary: I'm checking in the the two patches above as soon as the tree opens, and I'm re-assigning (the non-dogfood part of) this bug to somebody who knows about string-bundles.

re-assigning as noted above. I'll still be checking in the fixes to the asserts as soon as the tree opens.

All right, checked in both those patches after review by Ben Bucksch (original author of one of the files). You don't hit the asserts now, so the dogfood part of this bug is fixed. Recommend it be taken of dogfood radar.

remove the [dogfood+] and ETA for dogfood from the status whiteboard I think we should take the dogfood out from the keywords filed now.

Making [dogfood-] per ftang comment.

I won't have time to look into this problem in PR2. But, accept it first.

*** Bug 46354 has been marked as a duplicate of this bug. ***

May impact localization. CC'ing myself.

per i18n bug triage meeting, this bug is now nsbeta3+. Updated info: As described in a duplicate Bug 46354, we are now getting random strings like "Reset" and "Submit query" for these 2 buttons on Mac. These are no longer "???" but still incorrect. To reproduce this bug, 1. Send a message with a vCard from Comm 4.7x. 2. View it with Mozilla. Look at the wording on the 2 buttons. They are wrong. The should be: These should be: 1. View Complete Card/View Condensed Card 2. Add to Personal Address Book

CC'ing Gary.

Hi, Rich: Is there any reason we need to cache this stringBundle as global var in this file? http://lxr.mozilla.org/mozilla/source/mailnews/mime/cthandlers/vcard/mimevcrd.cp p#52 Would you mind moving it into functions as a local variable instead? StringBundle will be cached in necko.

The global variable, stringBundle, seems to be the culprit. Reassign to rhp for cleaning this up.

Is it just a variable name issue or scope issue? - rhp

Well, I can fix this for the Mac by making this a local variable on the Mac, but this is not a good fix! This will do nothing but make performance worse for vcards and that is a BAD thing to do to an already slow Mac product. I will not make that change to Win32 or Unix, but I'll try it on mac. - rhp

Just checked in a "fix" for the mac. - rhp

Re-open bug. It's back ... as Kat noted before, the button has the wrong text. It displays as "reset" instead of "View complete card" or "View condensed card" This occurs in today Mac commercial seamonkey build 2000-081404-m18.

Well, I did what was suggested so if this is still broken, its back to Tao. - rhp

Global variable is not thread-safe. I tried rhp's patch and that was not enough to fix the problem. I'll take another look.

It appears that opening this property stream: chrome://messenger/locale/vcard.properties fails on Mac. The return code is NS_OK but the returned stream is null. Reassign to warren for investigation.

I just logged a new bug 49422 against the NS_OpenURI() problem. Take this bug back.

The root cause is that chrome://messenger/locale/vcard.properties is not there at all; it got exported to wrong directory (viewer:res:messenger:messenger). cleanup dependency..

reassign to a mail/news person

who is on sabbatical. If this is a build script problem, I'm going to assign it to JF. Is it only on the mac that this file is getting exported to the wrong place?

yes

Accepting

here is the fix: Index: NGLayoutBuildList.pm =================================================================== RCS file: /cvsroot/mozilla/build/mac/NGLayoutBuildList.pm,v retrieving revision 1.564 diff -r1.564 NGLayoutBuildList.pm 966c966 < _InstallResources(":mozilla:mailnews:mime:cthandlers:resources:MANIFEST", "$mailnews_dir:messenger:", 0); --- > _InstallResources(":mozilla:mailnews:mime:cthandlers:resources:MANIFEST", "$messengerLocale", 0);

Fixed and checked in

Linux (2000-08-23-06 M18) Win32 (2000-08-23-08 M18) Mac (2000-08-23-08 M18) Vcard looks OK now in all platforms.