WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
10813
REGRESSION (
r16245
): double-clicking on javascript exceptions fails to show source
https://bugs.webkit.org/show_bug.cgi?id=10813
Summary
REGRESSION (r16245): double-clicking on javascript exceptions fails to show s...
Eric Seidel (no email)
Reported
2006-09-11 13:39:18 PDT
Regression: double-clicking on javascript exceptions fails to show source Perhaps this is specific to SVG files, not sure. Either way, this used to work.
Attachments
svg file containing bad javascript to trigger exception
(1.02 KB, image/svg+xml)
2006-09-11 13:57 PDT
,
Eric Seidel (no email)
no flags
Details
A hack-ish fix.
(699 bytes, patch)
2006-09-13 14:02 PDT
,
Eric Seidel (no email)
ap
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1
2006-09-11 13:57:13 PDT
Created
attachment 10506
[details]
svg file containing bad javascript to trigger exception
mitz
Comment 2
2006-09-11 15:31:07 PDT
The regression happend between in
r16245
(text encoding fixes,
bug 10728
). +[WebCoreFrameBridge stringWithData:textEncodingName:] is assumed to default to Latin-1 when passed nil for the encoding name, but nothing in the code supports it: TextEncoding just passes the nil down to atomicCanonicalTextEncodingName() which returns 0. The TextEncoding's m_encoding remains 0, and consequently it doesn't decode or encode.
Eric Seidel (no email)
Comment 3
2006-09-13 14:02:36 PDT
Created
attachment 10543
[details]
A hack-ish fix. Not sure if this is the right way to fix it or not.
Alexey Proskuryakov
Comment 4
2006-09-14 12:54:21 PDT
Comment on
attachment 10543
[details]
A hack-ish fix. r=me (yes, even without a ChangeLog entry ;) ) I think that this patch properly fixes the regression, but the behavior is still seriously broken. This code path is used when HTTP headers don't specify an encoding, but there are numerous other ways for WebCore to pick one, and the same encoding should be used for handling a resource and for providing it source, obviously. + NSString* name = textEncodingName ? textEncodingName : @"Latin-1"; We usually call this encoding "iso-8859-1". Might make sense to do so here for consistency, as well.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug