Last Comment Bug 315288 - define JS_C_STRINGS_ARE_UTF8 for non-ascii chars in Exceptions
: define JS_C_STRINGS_ARE_UTF8 for non-ascii chars in Exceptions
Status: RESOLVED WORKSFORME
[wanted-2.0]
: intl
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: mozilla2.0
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 352856 426137 (view as bug list)
Depends on:
Blocks: 232182 353107 353108 397215
  Show dependency treegraph
 
Reported: 2005-11-06 10:00 PST by Bob Clary [:bc:]
Modified: 2014-10-05 05:02 PDT (History)
17 users (show)
benjamin: blocking1.9-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1.0 (448 bytes, patch)
2005-11-08 23:40 PST, cls
benjamin: review+
Details | Diff | Review

Description Bob Clary [:bc:] 2005-11-06 10:00:45 PST
Needed for bug 232182
Comment 1 Blake Kaplan (:mrbkap) (please use needinfo!) 2005-11-08 14:12:50 PST
Are there any cases where we wouldn't want this defined?
Comment 2 Brendan Eich [:brendan] 2005-11-08 23:11:06 PST
Who "we"?  Makefile.ref shouldn't, but README.html should mention the new compile-time option.

/be
Comment 3 cls 2005-11-08 23:40:23 PST
Created attachment 202343 [details] [diff] [review]
v1.0

I would assume "we" means the gecko-based products since this is filed against Core:Build Config.  It seems like you're asking for a simple -DJS_STRINGS_ARE_UTF8 to be added unconditionally to the gecko build like we have for JS_THREADSAFE.
Comment 4 Benjamin Smedberg [:bsmedberg] 2005-11-10 08:43:29 PST
Comment on attachment 202343 [details] [diff] [review]
v1.0

Presuming from the commentary above that this has moa=brendan, sure.
Comment 5 cls 2005-11-10 15:30:14 PST
The patch has been checked in.
Comment 6 Brendan Eich [:brendan] 2005-11-12 11:15:12 PST
I backed out rev 1.1547 of configure.in till we have our heads screwed back on straight, and have adjusted JS API clients that need deflation to ISO-Latin-1 to avoid getting UTF-8.  My fault for not coordinating harder.

/be
Comment 7 Masayuki Nakano [:masayuki] (Mozilla Japan) 2005-11-12 14:46:54 PST
Brendan:

Please tell me, what problem do we have?
The patch has checked-in to Trunk. But you was backing-out it.
Does SeaMonkey or Firefox or Thunderbird have a problem?
Or third party's product?
If it's latter, I think that we cannot understand the reason of backing-out.
Otherwise, our product has some problem, should we use the patch for we fix all regressions?
Comment 8 James Ross 2005-11-12 14:54:38 PST
Please see bug 316178 comment 1. This has caused a very fundamental problem with XPConnect's conversion code.
Comment 9 Masayuki Nakano [:masayuki] (Mozilla Japan) 2005-11-12 16:42:12 PST
thanks for the pointer.
Comment 10 Boris Zbarsky [:bz] (Out June 25-July 6) 2006-03-05 09:40:52 PST
I don't see a way we can fix this problem, really -- we have tons of interfaces that abuse |string| and expect to somehow "work" for random data.  :(
Comment 11 Christian :Biesinger (don't email me, ping me on IRC) 2006-03-05 10:06:12 PST
xpconnect could convert using some other method that keeps the current behaviour.
Comment 12 Brendan Eich [:brendan] 2006-09-07 11:05:23 PDT
This should get attention during 1.9.

/be
Comment 13 Brendan Eich [:brendan] 2006-09-15 12:43:38 PDT
*** Bug 352856 has been marked as a duplicate of this bug. ***
Comment 14 Brendan Eich [:brendan] 2006-09-15 12:57:37 PDT
If this is too much for 1.9, it's definitely a Mozilla 2 to-do item, because we can and will break API compat.

/be
Comment 15 Marek Stępień [:marcoos, inactive] 2008-03-31 02:49:41 PDT
*** Bug 426137 has been marked as a duplicate of this bug. ***
Comment 16 Axel Hecht [:Pike] 2014-10-05 05:02:03 PDT
So much changed around encoding of js strings, the define doesn't exist anymore, I'll just resolve this WORKSFORME. Haven't heard of any of the issues mentioned here in the past few years, too.

Feel free to reopen if there's still a problem, though at this point, a new bug is probably better.

Note You need to log in before you can comment on or make changes to this bug.