[PATCH] mshtml: When creating new channel default to current locale charset.
Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> --- dlls/mshtml/nsio.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/dlls/mshtml/nsio.c b/dlls/mshtml/nsio.c index 7c8f029b4a..8cad9800a5 100644 --- a/dlls/mshtml/nsio.c +++ b/dlls/mshtml/nsio.c @@ -3372,6 +3372,7 @@ HRESULT create_doc_uri(IUri *iuri, nsWineURI **ret) static nsresult create_nschannel(nsWineURI *uri, nsChannel **ret) { nsChannel *channel; + BSTR bstr; if(!ensure_uri(uri)) return NS_ERROR_UNEXPECTED; @@ -3385,6 +3386,11 @@ static nsresult create_nschannel(nsWineURI *uri, nsChannel **ret) channel->nsIHttpChannelInternal_iface.lpVtbl = &nsHttpChannelInternalVtbl; channel->ref = 1; channel->request_method = METHOD_GET; + + bstr = charset_string_from_cp(GetACP()); + channel->charset = heap_strdupWtoA(bstr); + SysFreeString(bstr); + list_init(&channel->response_headers); list_init(&channel->request_headers); -- 2.26.2
Hi Dmitry, On 19/06/2020 05:19, Dmitry Timoshkov wrote:
@@ -3385,6 +3386,11 @@ static nsresult create_nschannel(nsWineURI *uri, nsChannel **ret) channel->nsIHttpChannelInternal_iface.lpVtbl = &nsHttpChannelInternalVtbl; channel->ref = 1; channel->request_method = METHOD_GET; + + bstr = charset_string_from_cp(GetACP()); + channel->charset = heap_strdupWtoA(bstr); + SysFreeString(bstr);
That's not how other nsIChannel implementations work in Gecko. As far as I can see, we should provide a charset only when we know it and let the caller figure out the default. I'm afraid that your change could break charset auto detection. I don't know what's the exact problem you're trying to fix, but we maybe we don't set it in some case when we should? Looking at Gecko code, I just noticed that we should try to extract it from content type in SetContentType(), for example. Thanks, Jacek
Jacek Caban <jacek(a)codeweavers.com> wrote:
@@ -3385,6 +3386,11 @@ static nsresult create_nschannel(nsWineURI *uri, nsChannel **ret) channel->nsIHttpChannelInternal_iface.lpVtbl = &nsHttpChannelInternalVtbl; channel->ref = 1; channel->request_method = METHOD_GET; + + bstr = charset_string_from_cp(GetACP()); + channel->charset = heap_strdupWtoA(bstr); + SysFreeString(bstr);
That's not how other nsIChannel implementations work in Gecko. As far as I can see, we should provide a charset only when we know it and let the caller figure out the default. I'm afraid that your change could break charset auto detection.
I don't know what's the exact problem you're trying to fix, but we maybe we don't set it in some case when we should? Looking at Gecko code, I just noticed that we should try to extract it from content type in SetContentType(), for example.
I have an application that includes many other .html files from its main.html. Main html has the following head: <html lang="ru"> <head> <meta http-equiv="Content-Type" content="text/html; charset=windows-1251"> <meta http-equiv="Content-Language" content="ru"> </head> and Wine's mshtml renders this file correctly. Main html includes another file with the following head: <html> <head> <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8"/> <meta content="text/html; charset=windows-1251"> </head> and this one renders using wrong locale. According to https://www.w3schools.com/charsets/default.asp both syntaxes are legal and should be supported starting from HTML 4. According to my testing when loading HTML gecko first queries charset from mshtml, it returns "", and then gecko renders page using wrong locale. With my patch gecko gets "windows-1251" and this fixes page rendering. Is this a bug in gecko or mshtml? -- Dmitry.
On 22.06.2020 12:08, Dmitry Timoshkov wrote:
Jacek Caban <jacek(a)codeweavers.com> wrote:
@@ -3385,6 +3386,11 @@ static nsresult create_nschannel(nsWineURI *uri, nsChannel **ret) channel->nsIHttpChannelInternal_iface.lpVtbl = &nsHttpChannelInternalVtbl; channel->ref = 1; channel->request_method = METHOD_GET; + + bstr = charset_string_from_cp(GetACP()); + channel->charset = heap_strdupWtoA(bstr); + SysFreeString(bstr);
That's not how other nsIChannel implementations work in Gecko. As far as I can see, we should provide a charset only when we know it and let the caller figure out the default. I'm afraid that your change could break charset auto detection.
I don't know what's the exact problem you're trying to fix, but we maybe we don't set it in some case when we should? Looking at Gecko code, I just noticed that we should try to extract it from content type in SetContentType(), for example. I have an application that includes many other .html files from its main.html. Main html has the following head:
<html lang="ru"> <head> <meta http-equiv="Content-Type" content="text/html; charset=windows-1251"> <meta http-equiv="Content-Language" content="ru"> </head>
and Wine's mshtml renders this file correctly. Main html includes another file with the following head:
<html> <head> <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8"/> <meta content="text/html; charset=windows-1251"> </head>
and this one renders using wrong locale.
According to https://www.w3schools.com/charsets/default.asp both syntaxes are legal and should be supported starting from HTML 4.
According to my testing when loading HTML gecko first queries charset from mshtml, it returns "", and then gecko renders page using wrong locale. With my patch gecko gets "windows-1251" and this fixes page rendering.
Is this a bug in gecko or mshtml?
The easiest way to check is it to write a trivial HTML file and try it on IE, Firefox (preferably 47, which is the version Wine Gecko bases on) and Wine iexplore.exe. The <meta> element in the second HTML looks suspicious, it doesn't have http-equiv="Content-Type" attribute. Does it help if you add one? Also, is the problem reproducible if you load the subframe as a main frame? Thanks, Jacek
Jacek Caban <jacek(a)codeweavers.com> wrote:
I don't know what's the exact problem you're trying to fix, but we maybe we don't set it in some case when we should? Looking at Gecko code, I just noticed that we should try to extract it from content type in SetContentType(), for example. I have an application that includes many other .html files from its main.html. Main html has the following head:
<html lang="ru"> <head> <meta http-equiv="Content-Type" content="text/html; charset=windows-1251"> <meta http-equiv="Content-Language" content="ru"> </head>
and Wine's mshtml renders this file correctly. Main html includes another file with the following head:
<html> <head> <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8"/> <meta content="text/html; charset=windows-1251"> </head>
and this one renders using wrong locale.
According to https://www.w3schools.com/charsets/default.asp both syntaxes are legal and should be supported starting from HTML 4.
According to my testing when loading HTML gecko first queries charset from mshtml, it returns "", and then gecko renders page using wrong locale. With my patch gecko gets "windows-1251" and this fixes page rendering.
Is this a bug in gecko or mshtml?
The easiest way to check is it to write a trivial HTML file and try it on IE, Firefox (preferably 47, which is the version Wine Gecko bases on) and Wine iexplore.exe.
It works on IE, I haven't tested with Firefox and Wine's iexplore.exe.
The <meta> element in the second HTML looks suspicious, it doesn't have http-equiv="Content-Type" attribute. Does it help if you add one?
Yes, it does help.
Also, is the problem reproducible if you load the subframe as a main frame?
How can I do that? -- Dmitry.
On 23.06.2020 17:35, Dmitry Timoshkov wrote:
Jacek Caban <jacek(a)codeweavers.com> wrote:
The <meta> element in the second HTML looks suspicious, it doesn't have http-equiv="Content-Type" attribute. Does it help if you add one? Yes, it does help.
It would still need more testing to be sure, but it sounds like <meta> handling is the main suspect. That part lives mostly in Gecko tree (except for X-UA-Compatible).
Also, is the problem reproducible if you load the subframe as a main frame? How can I do that?
My understanding is that in your case the second HTML is in <frame> or <iframe> element. You could just open it directly (but from above, it sounds like it's not related). Jacek
Jacek Caban <jacek(a)codeweavers.com> wrote:
The <meta> element in the second HTML looks suspicious, it doesn't have http-equiv="Content-Type" attribute. Does it help if you add one? Yes, it does help.
It would still need more testing to be sure, but it sounds like <meta> handling is the main suspect. That part lives mostly in Gecko tree (except for X-UA-Compatible).
I've created https://bugs.winehq.org/show_bug.cgi?id=49448 and attached problematic HTML to it. It seems to be a bug in Gecko. -- Dmitry.
participants (2)
-
Dmitry Timoshkov -
Jacek Caban