Closed Bug 239535 Opened 16 years ago Closed 15 years ago

[Mac] nsDateTimeFormatMac is broken in Japanese locale (Page Info fails to load / Media Tab doesn't work / Cookie Manager doesn't show "Expires")

Categories

(Core :: Internationalization, defect, major)

PowerPC
macOS
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: harunaga, Assigned: jhpedemonte)

References

()

Details

(4 keywords)

Attachments

(4 files, 1 obsolete file)

Page Info never finish loading at a certain page on Mac.

Steps:
1. Go to the URL above.
2. Open View -> Page Info.

JavaScript Console shows as follows:
Error: uncaught exception: [Exception... "Component returned failure code:
0x8000ffff (NS_ERROR_UNEXPECTED) [nsIScriptableDateFormat.FormatDateTime]" 
nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://navigator/content/pageInfo.js :: formatDate :: line 1017"  data: no]

Confirmed with 2004040105/MacOS 10.3.3.
2004031605/Mac has no problem.
2004031705/Mac has this problem.
regression.
On this page (Bug 239535), or http://www.mozillazine.org/,
loading can be done, but if you click Media tab in Page Info,
same JavaScript error occurs, and we can't use Media tab on Mac.
Summary: [Mac] Page Info never finish loading on some page → [Mac] Page Info never finish loading / Media Tab doesn't work
Is this caused by Bug 233631?
(In reply to comment #2)
> Is this caused by Bug 233631?

I'll try to do some testing. Apparently, I just changed
nsScriptableDateFormat::FormatDateTime to do the same thing as
nsIDateTimeFormat::FormatTime does, so the bug must be elsewhere. 
I cannot reproduce the problem. (I only have access to OS X 10.2.8.) 

Could you provide some more details? Does this problem occur in the Cookie
Manager or in any other instances where the date is shown? Are there any
assertions? 
Is this Mac OS 10.3.x only?

I can still reproduce comment 0 and comment 1
with 2004040805/Mac OS 10.3.3, even if I create a new profile.

Cookie Manager is also strange as expected by Constantine.
In "Stored Cookie", "Expires" are not displayed at all
although JavaScript Console shows nothing.
It reproduced.

Mac OS X 10.3.3 + New Profile
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040408
Javascript Console error message:
Error: uncaught exception: [Exception... "Component returned failure code:
0x8000ffff (NS_ERROR_UNEXPECTED) [nsIScriptableDateFormat.FormatDateTime]" 
nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://navigator/content/pageInfo.js :: formatDate :: line 1017"  data: no]
Moving to intl land.

Could someone provide ASSERTIONs that occur when this bug happens? 
Assignee: db48x → smontagu
Component: Page Info → Internationalization
Keywords: qawanted
QA Contact: amyy
If I set "English" as most preferred language in Mac OS "System Preferences"
-> Personal -> International -> Language, log out and log in,
then this problem disappears.
Loading is done, and Type, Source, Size, Expires, Dimensions, image
are displayed in Media tab.
And Cookie Manager also works fine.

In "Japanese" language, this problem occurs.
Keywords: intl
Summary: [Mac] Page Info never finish loading / Media Tab doesn't work → [Mac] Page Info never finish loading / Media Tab doesn't work in Japanese locale
Blocks: 240150
requesting blocking 1.7 because Page Info on Firefox 1.0/Mac will not
work for Japanese locale users.
Flags: blocking1.7?
I think we need to change the summary somehow to reflect the problem (like
"nsIScriptableDateFormat is broken in Japanese locale"). 

We need to narrow this problem. I do not have Japanese locale on the Macs I
have access to, so I cannot reproduce this problem at all. 

I am not sure that the following gives any help, but since no one else says
anything, I'll take the word. 

Reporters: try to open JavaScript Debugger and execute the lines from this
attachment. I am not sure that it will do any help, but it may give us some
idea of what the problem is. Try to use some other locales, combinations, etc. 


Also, please report if the time shows in MailNews and bookmarks manager.
It seems to me that MailNews and Bookmark Manager don't have this
problem.
JavaScript Debugger shows as follows on Japanese locale.
This error doesn't occur on English locale.

0001: z =
Components.classes["@mozilla.org/intl/scriptabledateformat;1"].createInstance();
[xpconnect wrapped nsISupports]
0002: for (a in Components.interfaces) z instanceof Components.interfaces[a];
false
0003: var date = new Date();
undefined
0004: z.FormatDateTime("", z.dateFormatLong, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
[Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED)
[nsIScriptableDateFormat.FormatDateTime]" nsresult: "0x8000ffff
(NS_ERROR_UNEXPECTED)" location: "JS frame ::
chrome://venkman/content/venkman-eval.js :: con_eval :: line 50" data: no]
0005: z.FormatDateTime("en-GB", z.dateFormatLong, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
Thu, Apr 29, 2004 9:23:00 am
0006: z.FormatDateTime("en-US", z.dateFormatLong, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
Thu, Apr 29, 2004 9:23:00 AM
0007: z.FormatDateTime("ru", z.dateFormatLong, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
Чт
0008: z.FormatDateTime("ja-JP", z.dateFormatLong, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
2004年 4月 29日 (木) 9:23:00 AM
0009: z.FormatDateTime("ko-KR", z.dateFormatLong, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
Thu, Apr 29, 2004 9:23:00 AM
00010: z.FormatDateTime("zh-CN", z.dateFormatLong, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
2004年4月29日週四, 9:23:00 AM
00011: z.FormatDateTime("", z.dateFormatShort, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
04.4.29 9:23:00 AM
00012: z.FormatDateTime("en-GB", z.dateFormatShort, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
29/4/04 9:23:00 am
00013: z.FormatDateTime("en-US", z.dateFormatShort, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
4/29/04 9:23:00 AM
00014: z.FormatDateTime("ru", z.dateFormatShort, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
29.04.2004 09:23:00
00015: z.FormatDateTime("ja-JP", z.dateFormatShort, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
04.4.29 9:23:00 AM
00016: z.FormatDateTime("ko-KR", z.dateFormatShort, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
4/29/04 9:23:00 AM
00017: z.FormatDateTime("zh-CN", z.dateFormatShort, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
2004/4/29 9:23:00 AM
00018: z.FormatDateTime("", z.dateFormatYearMonth, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
04/04 9:23:00 AM
00019: z.FormatDateTime("", z.dateFormatWeekday, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
木 9:23:00 AM
JavaScript Debugger on 1.6/Mac showed as follows in Japanese locale.

0004: z.FormatDateTime("", z.dateFormatLong, z.timeFormatSeconds,
date.getFullYear(), date.getMonth()+1, date.getDate(), date.getHours(),
date.getMinutes(), date.getSeconds());
2004年 5月 1日 (土) 10:14:12 PM

So default(?) dateFormatLong is broken in Japanese locale.
Summary: [Mac] Page Info never finish loading / Media Tab doesn't work in Japanese locale → [Mac] nsIScriptableDateFormat is broken in Japanese locale (Page Info never finish loading / Media Tab doesn't work)
(In reply to comment #13)
> So default(?) dateFormatLong is broken in Japanese locale.

No, nsDateTimeFormatMac is broken for the long date format, iff the locale is
Japanese and we do not pass the locale to nsDateTimeFormatMac explicitly (as I
can see from your comment 12). It just happens this way that no other place of
C++ Mozilla uses long date format, so it only shows up in JavaScript, i.e. in
nsIScriptableDateFormat. 

Here is the link for the code in question:
http://lxr.mozilla.org/mozilla/source/intl/locale/src/mac/nsDateTimeFormatMac.cpp

I will not have any time to look at it before next Tuesday, 2004-05-04. 
Blocks: dateandtime
Summary: [Mac] nsIScriptableDateFormat is broken in Japanese locale (Page Info never finish loading / Media Tab doesn't work) → [Mac] nsDateTimeFormatMac is broken in Japanese locale (Page Info never finish loading / Media Tab doesn't work)
not going to block the release for this but we'd consider taking a fully
reviewed patch if someone can come up with one before 1.7 ships.
Flags: blocking1.7? → blocking1.7-
*** Bug 240150 has been marked as a duplicate of this bug. ***
Keywords: helpwanted
Summary: [Mac] nsDateTimeFormatMac is broken in Japanese locale (Page Info never finish loading / Media Tab doesn't work) → [Mac] nsDateTimeFormatMac is broken in Japanese locale (Page Info fails to load / Media Tab doesn't work / Cookie Manager doesn't show "Expires")
removing duplicate from dependencies
No longer blocks: 240150
When opening Page Info at http://www.mozilla.org/ in Japanese locale
on Mac 10.3.4,  I can see the followings which are different from those
in English locale.

^C
Program received signal SIGINT, Interrupt.
0x900074c8 in mach_msg_trap ()
(gdb) b nsDateTimeFormatMac::FormatTime
Breakpoint 1 at 0x48201a8: file nsDateTimeFormatMac.cpp, line 330.
(gdb) c
Continuing.
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
WARNING: the property eo already exists
, file nsPersistentProperties.cpp, line 282
Document http://www.mozilla.org/ loaded successfully
++WEBSHELL == 4
++DOMWINDOW == 4
XP Popups: This is a nag to indicate that an inconsistent hack is being done on
the Mac for popups.
WARNING: trying to find screen for sizeless window, using primary monitor, file
nsScreenManagerMac.cpp, line 119

Breakpoint 1, nsDateTimeFormatMac::FormatTime(nsILocale*, int, int, long,
nsString&) (this=0x10a89090, locale=0x0, dateFormatSelector=1,
timeFormatSelector=1, timetTime=1085094152, stringOut=@0xffcd43c) at
nsDateTimeFormatMac.cpp:330
330       return FormatTMTime(locale, dateFormatSelector, timeFormatSelector,
localtime(&timetTime), stringOut);
(gdb) n
331     }
(gdb) n
nsScriptableDateFormat::FormatDateTime(unsigned short const*, int, int, int,
int, int, int, int, int, unsigned short**) (this=0xffcd430, aLocale=0x1117a90,
dateFormatSelector=1, timeFormatSelector=1, year=2004, month=5, day=21, hour=8,
minute=2, second=32, dateTimeString=0x10a89080) at nsScriptableDateFormat.cpp:153
153       if (NS_SUCCEEDED(rv))
(gdb) n
156       return rv;
(gdb) p rv
$2 = 2147549183
(gdb) n
157     }
(gdb) n
0x01c44a84 in _XPTC_InvokeByIndex () at nsTObsoleteAStringThunk.cpp:51
51            static const void* get_vptr()
(gdb) c
Continuing.
JavaScript error: , line 0: uncaught exception: [Exception... "Component
returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED)
[nsIScriptableDateFormat.FormatDateTime]"  nsresult: "0x8000ffff
(NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://navigator/content/pageInfo.js :: formatDate :: line 1013"  data: no]
(In reply to comment #18)
> (gdb) b nsDateTimeFormatMac::FormatTime

Could you try to break it on FormatTMTime instead? That is the function that the
error occurs. Thanks. 
(In reply to comment #19)
> Could you try to break it on FormatTMTime instead?

^C
Program received signal SIGINT, Interrupt.
0x900074c8 in mach_msg_trap ()
(gdb) b nsDateTimeFormatMac::FormatTMTime
Breakpoint 1 at 0x483cabc: file nsDateTimeFormatMac.cpp, line 355.
(gdb) c
Continuing.
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
WARNING: the property eo already exists
, file nsPersistentProperties.cpp, line 282
Document http://www.mozilla.org/ loaded successfully
++WEBSHELL == 4
++DOMWINDOW == 4
XP Popups: This is a nag to indicate that an inconsistent hack is being done on
the Mac for popups.
WARNING: trying to find screen for sizeless window, using primary monitor, file
nsScreenManagerMac.cpp, line 119

Breakpoint 1, nsDateTimeFormatMac::FormatTMTime(nsILocale*, int, int, tm const*,
nsString&) (this=0x10d851d0, locale=0x0, dateFormatSelector=1,
timeFormatSelector=1, tmTime=0x115bed0, stringOut=@0x102c90bc) at
nsDateTimeFormatMac.cpp:355
355       (void) Initialize(locale);
(gdb) n
358       if (dateFormatSelector == kDateFormatNone && timeFormatSelector ==
kTimeFormatNone) {
(gdb) n
363       stringOut.AssignWithConversion(asctime(tmTime));      // set the
default string, in case for API/conversion errors
(gdb) n
366       NS_ASSERTION(tmTime->tm_mon >= 0, "tm is not set correctly");
(gdb) n
367       NS_ASSERTION(tmTime->tm_mday >= 1, "tm is not set correctly");
(gdb) n
368       NS_ASSERTION(tmTime->tm_hour >= 0, "tm is not set correctly");
(gdb) n
369       NS_ASSERTION(tmTime->tm_min >= 0, "tm is not set correctly");
(gdb) n
370       NS_ASSERTION(tmTime->tm_sec >= 0, "tm is not set correctly");
(gdb) n
371       NS_ASSERTION(tmTime->tm_wday >= 0, "tm is not set correctly");
(gdb) n
373       macDateTime.year = tmTime->tm_year + 1900;
(gdb) n
377       macDateTime.month = tmTime->tm_mon + 1;
(gdb) n
378       macDateTime.day = tmTime->tm_mday;
(gdb) n
379       macDateTime.hour = tmTime->tm_hour;
(gdb) n
380       macDateTime.minute = tmTime->tm_min;
(gdb) n
381       macDateTime.second = tmTime->tm_sec;
(gdb) n
385       macDateTime.dayOfWeek = tmTime->tm_wday +1 ; 
(gdb) n
387       ::DateToSeconds( &macDateTime, (unsigned long *) &dateTime);
(gdb) n
390       Handle itl1Handle = mUseDefaultLocale ? nil : (Handle)
GetItl1Resource(mScriptcode, mRegioncode);
(gdb) n
391       Handle itl0Handle = mUseDefaultLocale ? nil : (Handle)
GetItl0Resource(mScriptcode, mRegioncode);
(gdb) n
394       if (timeFormatSelector != kTimeFormatNone) {
(gdb) n
396         if ( itl0Handle &&
(gdb) n
406           ::TimeString(dateTime, (timeFormatSelector == kTimeFormatSeconds),
timeString, itl0Handle);
(gdb) n
411       switch (dateFormatSelector) {
(gdb) n
413           ::DateString(dateTime, abbrevDate, dateString, itl1Handle);
(gdb) n
414           break;
(gdb) n
433       if (dateFormatSelector != kDateFormatNone && timeFormatSelector !=
kTimeFormatNone) {
(gdb) n
434         CopyPascalStringToC(dateString, localBuffer);
(gdb) n
435         localBuffer[dateString[0]] = ' ';
(gdb) n
436         CopyPascalStringToC(timeString, &(localBuffer[dateString[0] + 1]));
(gdb) n
446       if (mDecoder) {
(gdb) n
447         PRInt32 srcLength = (PRInt32) PL_strlen(localBuffer);
(gdb) n
448         PRInt32 unicharLength = sizeof(Str255)*2;
(gdb) n
451         res = mDecoder->Convert(localBuffer, &srcLength, unichars,
&unicharLength);
(gdb) n
452         if (NS_SUCCEEDED(res)) {
(gdb) n
457       return res;
(gdb) p res
$1 = 2147549183
(gdb) n
458     }
(gdb) n
nsDateTimeFormatMac::FormatTime(nsILocale*, int, int, long, nsString&)
(this=0x10d851d0, locale=0x0, dateFormatSelector=1, timeFormatSelector=1,
timetTime=1086801448, stringOut=@0x102c90bc) at nsDateTimeFormatMac.cpp:331
331     }
(gdb) n
nsScriptableDateFormat::FormatDateTime(unsigned short const*, int, int, int,
int, int, int, int, int, unsigned short**) (this=0x102c90b0, aLocale=0x1117a80,
dateFormatSelector=1, timeFormatSelector=1, year=2004, month=6, day=10, hour=2,
minute=17, second=28, dateTimeString=0x10d851c0) at nsScriptableDateFormat.cpp:153
153       if (NS_SUCCEEDED(rv))
(gdb) c
Continuing.
JavaScript error: , line 0: uncaught exception: [Exception... "Component
returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED)
[nsIScriptableDateFormat.FormatDateTime]"  nsresult: "0x8000ffff
(NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://navigator/content/pageInfo.js :: formatDate :: line 1013"  data: no]
additional test in Japanese locale:

Oops, I can't send the log as commment.  Making an attachment instead.
Attachment #146060 - Attachment is obsolete: true
Firefox 0.9 has been released.
Workaround by hard coding for Japanese locale users:

1. copy browser.jar to somewhere and extract it.
2. modify FormatDateTime("" to FormatDateTime("ja-JP"
   in browser/pageInfo.js and browser/cookieviewer/CookieViewer.js
3. archive back content/ as browser.jar.
4. replace the original browser.jar with this.
requesting blocking 1.7.1
Flags: blocking1.7.1?
The minimum testcase must be:

z = Components.classes["@mozilla.org/intl/scriptabledateformat;1"].createInstance();

for (a in Components.interfaces) z instanceof Components.interfaces[a];

z.FormatDateTime("ja-JP", z.dateFormatLong, z.timeFormatSeconds, 2004, 1, 1, 0,
0, 0);
z.FormatDateTime("", z.dateFormatLong, z.timeFormatSeconds, 2004, 1, 1, 0, 0, 0);

Probably, breaking the code both times at nsDateTimeFormatMac::FormatTMTime and
at nsIUnicodeDecoder::Convert, and comparing the stacks could reveal the source
of the problem. 
Blocks: 103669
Can anybody check the status of this bug with the patch for bug 252475
(In reply to comment #25)
> The minimum testcase must be:

Yes.

0001: z =
Components.classes["@mozilla.org/intl/scriptabledateformat;1"].createInstance();
[xpconnect wrapped nsISupports]
0002: for (a in Components.interfaces) z instanceof Components.interfaces[a];
false
0003: z.FormatDateTime("ja-JP", z.dateFormatLong, z.timeFormatSeconds, 2004, 1,
1, 0, 0, 0);
2004年 1月 1日 (木) 0:00:00 AM
0004: z.FormatDateTime("", z.dateFormatLong, z.timeFormatSeconds, 2004, 1, 1, 0,
0, 0);
[Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED)
[nsIScriptableDateFormat.FormatDateTime]" nsresult: "0x8000ffff
(NS_ERROR_UNEXPECTED)" location: "JS frame ::
chrome://venkman/content/venkman-eval.js :: con_eval :: line 50" data: no]

> Probably, breaking the code both times at nsDateTimeFormatMac::FormatTMTime and
> at nsIUnicodeDecoder::Convert, and comparing the stacks could reveal the source
> of the problem. 

(gdb) b nsIUnicodeDecoder::Convert
the class nsIUnicodeDecoder does not have any method named Convert

What should I do?

Re: comment 26:

JavaScript code in bug 252475 comment 0 returns "ja-JP" in Japanese
Language/Format.
So I think that bug 252475 is probably different from this...
Attached patch patchSplinter Review
The 0x8000ffff error comes from UnicodeDecoder->Convert failing to convert the
date/time string to the user's language.  The reason is that the unicode
decoder is created using mSystemCharset, which is the filesystem's encoding; 
this is always "UTF-8" on MacOSX.  We should always be using mCharset to create
the unicode decoder.

This is the quick patch.  For 10.3, we need to switch to the new APIs. I'll try
to create a patch for that also.
Assignee: smontagu → jhpedemonte
Status: NEW → ASSIGNED
Attached image PageInfo of a SSL page
https://register.www.infoseek.co.jp/Login?appRedirect=http://email.www.infoseek.co.jp/


The certificate cannot be seen in PageInfo of a SSL page.
And tt does not react, even if it pushes the View button.
(When applying the patch of comment#23, it was able to see normally.)

This may be a very serious problem.
It desires to be repaired in the next release.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7) Gecko/20040802
Firefox/0.9.1+
Flags: blocking-aviary1.0?
QA Contact: amyy → cnst+bmo
Comment on attachment 154694 [details] [diff] [review]
patch

This patch looks fine to me. 

harunaga, could you confir that it solves the problem? 

jhpedemonte, could you request reviews? Let's fix this for now, and switch to
the new APIs later (in a different bug).
(In reply to comment #30)
> harunaga, could you confir that it solves the problem? 

The patch works fine for me in the Japanese Language environment
on Mac OS 10.3.5.
With this patch, it is working also by Firefox of aviary branch.
The problem of comment#29 is also Fixed!!

Mac OS X 10.3.5
Attachment #154694 - Flags: superreview?(roc)
Attachment #154694 - Flags: review?(jshin)
Comment on attachment 154694 [details] [diff] [review]
patch

r=jshin

After getting sr, let's get this in for branches. Then, on trunk, we should
make a new patch that uses new APIs.
Attachment #154694 - Flags: review?(jshin) → review+
Attachment #154694 - Flags: superreview?(roc) → superreview+
Comment on attachment 154694 [details] [diff] [review]
patch

Requesting approvals for aviari and 1.7.x. 

jshin: could you commit the patch to the trunk in the meantime?
Attachment #154694 - Flags: approval1.7.x?
Attachment #154694 - Flags: approval-aviary?
Comment on attachment 154694 [details] [diff] [review]
patch

a=asa for branch checkins.
Attachment #154694 - Flags: approval1.7.x?
Attachment #154694 - Flags: approval1.7.x+
Attachment #154694 - Flags: approval-aviary?
Attachment #154694 - Flags: approval-aviary+
Whiteboard: [have patch] → 4
Patch checked in everywhere.  Is there already a bug open for moving to the new
APIs on the trunk?
Whiteboard: 4
removing blcoking? flags.
Flags: blocking1.7.x?
Flags: blocking-aviary1.0?
Bug for new APIs is bug 105045.  Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.