Closed
Bug 315288
Opened 19 years ago
Closed 10 years ago
define JS_C_STRINGS_ARE_UTF8 for non-ascii chars in Exceptions
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
mozilla2.0
People
(Reporter: bc, Unassigned)
References
Details
(Keywords: intl, Whiteboard: [wanted-2.0])
Attachments
(1 file)
448 bytes,
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
Needed for bug 232182
Comment 1•19 years ago
|
||
Are there any cases where we wouldn't want this defined?
Comment 2•19 years ago
|
||
Who "we"? Makefile.ref shouldn't, but README.html should mention the new compile-time option. /be
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.
Attachment #202343 -
Flags: review?(benjamin)
Comment 4•19 years ago
|
||
Comment on attachment 202343 [details] [diff] [review] v1.0 Presuming from the commentary above that this has moa=brendan, sure.
Attachment #202343 -
Flags: review?(benjamin) → review+
The patch has been checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
Comment 6•19 years ago
|
||
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 7•19 years ago
|
||
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•19 years ago
|
||
Please see bug 316178 comment 1. This has caused a very fundamental problem with XPConnect's conversion code.
Comment 9•19 years ago
|
||
thanks for the pointer.
Comment 10•18 years ago
|
||
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•18 years ago
|
||
xpconnect could convert using some other method that keeps the current behaviour.
Comment 12•18 years ago
|
||
This should get attention during 1.9. /be
Flags: blocking1.9?
Summary: define JS_STRINGS_ARE_UTF8 for non-ascii chars in Exceptions → define JS_C_STRINGS_ARE_UTF8 for non-ascii chars in Exceptions
Comment 13•18 years ago
|
||
*** Bug 352856 has been marked as a duplicate of this bug. ***
No longer blocks: 352856
Comment 14•18 years ago
|
||
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
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-2.0]
Updated•16 years ago
|
Assignee: nobody → general
Status: REOPENED → NEW
Target Milestone: mozilla1.9alpha1 → mozilla2.0
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Comment 16•10 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 19 years ago → 10 years ago
Resolution: --- → WORKSFORME
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•