WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
27802
Encoding override is not applied to all the contents in the page.
https://bugs.webkit.org/show_bug.cgi?id=27802
Summary
Encoding override is not applied to all the contents in the page.
johnnyding
Reported
2009-07-29 06:30:32 PDT
(Original bug was filed by Jungshik) Ideally, When 'character encoding' is overriden manually by a user (in View > Text Encoding menu), that encoding should be applied to all contents and frames (main and subframes loaded in a few different ways - JS, iframe, frame, AJAX). But now WebKit's behavior is not. Jungshik described a testcase in chromium bug:
http://code.google.com/p/chromium/issues/detail?id=7243
After analyzing the case, some contents don't change is because those contents are generated by external JS file, and the encoding in the C-T head of the external JS files is "EUC-KR". Now if there is encoding defined in C-T head of external JS resource, WebKit will use it to decode the contents of JS resource. (See Loader::Host::didReceiveResponse and CacheScript::setEncoding). To comply with IE's behavior, it looks like we need to give high priority to the override encoding when decoding the external js resource. But now FF3 preferntially tries to use the encoding declared in C-T header if it's available, like current WebKit does. If we decide to use IE's way. I have a patch to make it work.
Attachments
patch v1 for loader
(2.23 KB, patch)
2009-07-29 06:36 PDT
,
johnnyding
ap
: review-
Details
Formatted Diff
Diff
patch v2 for loader
(3.75 KB, patch)
2009-07-30 06:02 PDT
,
johnnyding
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
johnnyding
Comment 1
2009-07-29 06:36:51 PDT
Created
attachment 33713
[details]
patch v1 for loader
Alexey Proskuryakov
Comment 2
2009-07-29 07:44:26 PDT
Comment on
attachment 33713
[details]
patch v1 for loader This looks closely related to
bug 22952
, probably even a duplicate. It's definitely a bug, as WebCore caching shouldn't affect how pages look. But I don't think that the fix is sufficient - it changes the globally cached resource text when encoding override is in effect, but other documents may be using the same resource with other encodings, so they will be broken. E.g., if you open a page, set an encoding override, and then open the same page in a new window, subresources will be taken from cache with a wrong (overridden) encoding.
johnnyding
Comment 3
2009-07-29 20:59:14 PDT
Thanks, Alexey. You are right, I shouldn't change the encoding of the global cached resource. A way comes to my mind to fix this issue is to 1) Firstly check the whether override encoding of revalidate resource is equal with the existing encoding of the base cached source(m_resourceToRevalidate). If yes, we done. 2) If no, we keep the revalidate resource and copy the data from base cached source. Then change the encoding of revalidate resource to override encoding. Is the way OK?
johnnyding
Comment 4
2009-07-30 06:02:08 PDT
Created
attachment 33775
[details]
patch v2 for loader Alex, the patch v2 used the way I mentioned in comments #3. Please take a look. Thanks!
johnnyding
Comment 5
2009-07-30 06:24:36 PDT
Please ignore my patch, I found a problem, will send the patch v2 later. Sorry for inconvenience.
Alexey Proskuryakov
Comment 6
2009-07-30 11:39:36 PDT
Comment on
attachment 33775
[details]
patch v2 for loader Clearing review flag per the above comment.
Alexey Proskuryakov
Comment 7
2009-07-30 15:11:24 PDT
By the way, if your patch will also fix
bug 22952
, I'd suggest posting it there, as it's much older.
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