Summary: | RealPlayer.GetTitle() Crashes Safari/Dashboard | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | mathias meyer <mathmeye> | ||||||||
Component: | Plug-ins | Assignee: | Alexey Proskuryakov <ap> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | ||||||||||
Priority: | P1 | ||||||||||
Version: | 420+ | ||||||||||
Hardware: | Mac | ||||||||||
OS: | OS X 10.4 | ||||||||||
Attachments: |
|
Description
mathias meyer
2005-09-28 05:21:33 PDT
Created attachment 4098 [details]
testcase that causes the crash
attached a little test that causes the crash. note that this works for any
property that is not set. in this rm
stream you might call GetAuthor (as it returns a string) but not GetTitle. If
author is not defined this will
crash Safari as well...
analog crash today with quicktime...
this might not belong here but anyway: replace the 'GetTitle' function above with the QT equivalent 'GetTrackName', adjust type of embedded stream and point to a quicktime stream. Using the 'GetTrackName' function without the required index, ie GetTrackName() instead of GetTrackName(int index) will crash safari... The problem here is that the plugin returns an incorrectly encoded string - NPString should be UTF-8, but RealPlayer uses some other encoding. I have a partial workaround that stops crashes, but doesn't always decode the returned strings correctly. Please report this issue to Real, as well. The other issues mentioned here sound like separate ones. Created attachment 6029 [details]
proposed fix
I have thought about a correct encoding to be used as a fallback a lot, but still have big reservations about it... I chose kCFStringEncodingWindowsLatin1 (AKA windows-1252), because:
1) I'm running a system with primary Russian, and "LATIN SMALL LETTER A WITH RING ABOVE" was still encoded as 0xE5, and not turned into a question mark or something. So. RealPlayer either treats its strings as dumb 8-bit buffers, or applies a Roman-only Mac<->Windows conversion. It's impossible to decide from this test case, because 0xe5 has the same meaning in both encodings.
2) CFStringGetSystemEncoding() is inappropriate - if we were to depend on the system primary language, we'd need the closest Windows encoding, not a Mac one.
Firefox simply stops decoding the string when it sees an invalid byte (so, the name is displayed as "P1 - Fr" in the test case).
Thoughts?
Comment on attachment 6029 [details]
proposed fix
Looks good to me. r=me
I have found a few more RealAudio files to test - apparently, the plugin indeed passes Windows-encoded strings without any modification; and the standalone player uses the system (or maybe application) encoding, which also results in broken display. Anyway, the real fix should be in the plugin itself. Landed the patch. I was wrong thinking that kCFStringEncodingWindowsLatin1 has no "holes". Will have to switch to kCFStringEncodingISOLatin1, although it's most certainly not the exact encoding of the strings coming from Flash. Comment on attachment 6029 [details]
proposed fix
Clearing the review flag from an already landed patch, so that it doesn't appear in the "patches waiting to be landed" queue.
Created attachment 6379 [details]
use ISO Latin1
Comment on attachment 6379 [details]
use ISO Latin1
r=me
|