Closed Bug 426137 Opened 16 years ago Closed 16 years ago

CAPS error messages not compatible with UTF-8 strings

Categories

(Core :: Security: CAPS, defect)

Product:
Core
Component:
Security: CAPS
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 315288

People

(Reporter: marcoos, Unassigned)

Details

Attachments

(1 file)

Screenshot from the JS console
11.95 KB, image/png
Details 
CallMethodDenied property from caps.properties (and probably others) using multibyte characters when displayed is malformed, e.g. in the Polish localization you get "Nie udzielono uprawnieD do wywoBania metody" instead of the correct the "Nie udzielono uprawnień do wywołania metody", as in the attached screenshot.
I've been going through what I think is the code path, and I think that caps is doing what it should.

Here is what I think happens:

We get CallMethodDenied, and hit the code at 

http://mxr.mozilla.org/mozilla/source/caps/src/nsScriptSecurityManager.cpp#862

That calls into SetPendingException, which sends a PRUnichar* with a %hs formatting into js land. That should convert the message into an UTF-8 char*. Under the assumption that JS_CStringsAreUTF8 is true. I don't see why it shouldn't, but maybe I'm wrong.

It's either that, or it could be that we're doing something wrong when getting the exception back out of js into something that the error console digests.

CCing a few folks for xpconnect and js help.

After reading, I'm more inclined to blame xpconnect that js engine, so I'm moving the bug over there.
Assignee: dveditz → nobody
Component: Security: CAPS → XPConnect
QA Contact: caps → xpconnect
(In reply to comment #1)
> It's either that, or it could be that we're doing something wrong when getting
> the exception back out of js into something that the error console digests.

The message is garbled the same way in Firebug (though I haven't checked how Firebug gets it)...
Marek, is this a regression from 2.0 or is that broken there as well?

As a datapoint, just throw "Kärcher" works,

data:text/html;charset=utf-8,<!DOCTYPE HTML PUBLIC "-%2F%2FW3C%2F%2FDTD HTML 4.0%2F%2FEN">%0D%0A<html lang%3D"en">%0D%0A <head>%0D%0A  <title>Test<%2Ftitle>%0D%0A  <style type%3D"text%2Fcss">%0D%0A  <%2Fstyle>%0D%0A <%2Fhead>%0D%0A <body>%0D%0A  <script type%3D"text%2Fjavascript">throw "Kärcher"<%2Fscript>%0D%0A <%2Fbody>%0D%0A<%2Fhtml>%0D%0A
This is a duplicate of bug 315288. Sorry for the noise.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
(In reply to comment #1)
> Under the assumption that JS_CStringsAreUTF8 is true. I don't see why it
> shouldn't, but maybe I'm wrong.

That assumption is not true as we currently build.



Is there a way to get a unicode error message into js? It clearly exists internally, as I successfully threw "Kärcher". I didn't find anything helpful in jsapi.h, though. Which might very well just be me.

Just wondering if there's a different thing that caps could call into and be fine.
(In reply to comment #6)
> Is there a way to get a unicode error message into js? It clearly exists
> internally, as I successfully threw "Kärcher". 

Please try throwing something else than an ISO-8859-1-encodable string, e.g. "żółć". The CAPS messages do support non-ASCII *Western* European characters, as discussed in bug 232182. 


Hihihi, sob, 

Error: uncaught exception: |óB

Sob #2, that localization note was never added :-(

Doesn't look like there's a whole lot to fix right now, other than to actually get a bug filed on the localization note and a test to figure out which locales are affected?

Marek, are you sure your list of entries in bug 232182 was complete?
# EnableCapabilityDenied, GetPropertyDenied, SetPropertyDenied, CallMethodDenied 
# CreateWrapperDenied, CheckLoadURIError and CheckSameOriginError.


PS: For the sake of hygiene, I'm moving this bug back to caps, it's really a dupe of a js bug exposed there.
Component: XPConnect → Security: CAPS
Actually, this is the list from the final version of the patch in that bug:

# EnableCapabilityDenied, GetPropertyDenied, SetPropertyDenied, CallMethodDenied 
# and CreateWrapperDenied.


can you throw \\uXXXX instead? If your goal is only the console reporter, we should probably be able to make it convert \\uXXXX.

alternatively, embed a data:text/plain;base64, url. we should be able to coordinate w/ the console reporter to make it linkify urls.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: