Closed Bug 1497948 Opened Last year Closed Last year
OS pref Reader can't read my .plist file
When I call prefReader.readPreferences(), I get the following exception: "JSON.parse: unexpected non-whitespace character after JSON data at line 346 column 1 of the JSON data" I'm attaching the .plist file that _I think_ is the one being used, but I'm not entirely sure how to tell. I'm using a regular Nightly, and I got this file from ~/Library/Preferences/org.mozilla.nightly.plist
You should be able to reproduce this with a local build. Is this true? If so, could you add the following line after w.End() and tell us what gets printed in the Terminal when you launch your local build via ./mach run? There may be some personally identifying information, so feel free to send to me via email. NSLog(@"ReadPreferences:\n%s", jsonStr.get());  https://dxr.mozilla.org/mozilla-central/source/xpcom/base/nsMacPreferencesReader.mm#88
(sent via email)
For some reason, storing the intermediate string as an nsCString in the StringWriteFunc and then converting to UTF16 resulted in a string that couldn't be parsed by JS_ParseJSON. I haven't had time to isolate the reason for this, but storing the intermediate string as an nsAString solves the issue and appears to match what we do elsewhere in the code base.
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED
Attachment #9016910 - Flags: review?(mstange)
Comment on attachment 9016910 [details] [diff] [review] Patch Review of attachment 9016910 [details] [diff] [review]: ----------------------------------------------------------------- Hmm yeah I don't understand why converting the strings piecemeal would have different results from converting the concatenation of them. Oh well.
Attachment #9016910 - Flags: review?(mstange) → review+
Well, I can see some NUL bytes in the attached plist, but I don't know what behavior that results in. Or even what behavior we would want from it.
https://hg.mozilla.org/integration/mozilla-inbound/rev/1f542a1a1b9892b3b963724e3252c74585107b92 Bug 1497948: Ensure that enterprise policies are converted into a correct UTF-16 string that can be parsed by JS_ParseJSON on macOS. r=mstange
(In reply to Markus Stange [:mstange] from comment #5) > Well, I can see some NUL bytes in the attached plist, but I don't know what > behavior that results in. Or even what behavior we would want from it. I was able to reproduce the issue by setting an invalid policy as follows: defaults write org.mozilla.nightly TestPolicy "São Paulo" It appears that the `ã` character is enough to trigger this issue.
Thanks, i verified that it fixed the problem for me
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.