333261 - scriptableunicodeconverter unavailable when building with native uconv support

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[Mike Hommey [:glandium]]

The scriptableunicodeconverter, which is used (at least) by chatzilla, is not included when building with native uconv (ac_add_options --enable-native-uconv)

Patch following

Comment 1

[Mike Hommey [:glandium]]

Attachment: Patch for the issue

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 3

[timeless]

sorry :)

*** This bug has been marked as a duplicate of 342133 ***

Comment 4

[Mike Hommey [:glandium]]

This is not a duplicate. Some applications, such as chatzilla use the scriptableunicodeconverter. Whether they should or not is not the point either. They do use it, and they fail to run properly with native uconv support since it doesn't provide the scriptableunicodeconverter, thus this bug.

Reopening.

Comment 5

[Simon Montagu :smontagu]

My own feeling is that we should take this and WONTFIX bug 342133, but that is more for superreviewers and/or drivers to decide.

Comment 6

[Benjamin Smedberg]

Native uconv is only for use in the minimal embedding profile for small devices. In that profile we do want XMLHttpRequest to work (bug 342133), but we don't care about CZ etc.

Comment 7

[Mike Hommey [:glandium]]

I fail to see why you don't want to use system libraries when possible. It helps unbloating the whole thing.

Comment 8

[Brendan Eich [:brendan]]

(In reply to comment #7)
> I fail to see why you don't want to use system libraries when possible. It
> helps unbloating the whole thing.

I think we should try to use system libraries where they are correct enough for the web (all locales).  On Windows, there was also an issue of depending on a library that might not be on all systems we support (or supported, at the time this came up).  And IIRC, when this was discussed last, it seemed the Windows code wasn't good enough for important locales.  See bug 332646.

/be

Comment 9

[Brendan Eich [:brendan]]

Cc'ing roc and dbaron for their thoughts.

Again, I would love to use system uconv if it's good enough and interoperable.  Mozilla code goes back to before 1998, when OSes were relatively impoverished and we had to do more ourselves.  Here's hoping we can shed some of that weight.

/be

Comment 10

[Brendan Eich [:brendan]]

Cc'ing darin and vlad too.

/be

Comment 11

[Doug Turner (:dougt)]

native uconv does not work correctly under Win32.  See bug 332646.  

I agree with the first part of comment 5, we should take this fix.  I have been ask for this interface in Minimo.

Comment 12

[Benjamin Smedberg]

I tend to disagree: using native libraries in general is going to buy us incompatibilities across platforms and/or the inability to fix our own bugs. It's better to carry our dependencies and have control over them.

Not saying that we shouldn't take this patch since Debian wants to (and is able to) maintain this build option.

Comment 13

[Doug Turner (:dougt)]

The core problem here is that uconv is fat and we need to spend some time reducing the data size of this part of our codebase.  

Comment 14

[Brendan Eich [:brendan]]

(In reply to comment #12)
> I tend to disagree: using native libraries in general is going to buy us
> incompatibilities across platforms and/or the inability to fix our own bugs.
> It's better to carry our dependencies and have control over them.

It's hard to generalize, but we don't use our own user-level (setcontext-based) threads.  We don't use our own malloc.  Etc.  Given long-standing well-written standards, some system libraries are usable on all OSes.  My point is that we should aspire to increase the size of that set, not resist it by marrying our own alternatives.  One way to avoid over-binding is to support both.

/be

Comment 15

[timeless]

since the fix is the same, this is a dupe, and was a dupe when i resolved it. bugs are about the changes they make, not their summaries.

*** This bug has been marked as a duplicate of 342133 ***

Comment 16

[Mike Hommey [:glandium]]

No, it is not a dupe. This bug is about scriptableunicodeconverter unavailable when building with native uconv support, not about xmlhttpheaders failing with native uconv. The fix is not the same.

Comment 17

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: merged to trunk

this bug isn't about whether native uconv is a good or bad thing. per comment 5 and the r=smontagu, this patch has enough approvals to land. I'm checking this in.

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

Checking in intl/uconv/src/Makefile.in;
/cvsroot/mozilla/intl/uconv/src/Makefile.in,v  <--  Makefile.in
new revision: 1.89; previous revision: 1.88
done
Checking in intl/uconv/src/nsUConvModule.cpp;
/cvsroot/mozilla/intl/uconv/src/nsUConvModule.cpp,v  <--  nsUConvModule.cpp
new revision: 1.59; previous revision: 1.58
done

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

sigh, I forgot to mention "native" in the checkin comment and forgot to mention the author of the patch. I suck; my apologies.

Comment 20

[timeless]

mike: this is the same bug because the reason xlmhttprequest didn't work is because the scriptableunicodeconverter wasn't available. the fix to that bug was to do precisely this. please read patches not just bug summaries.