From: Jacek Caban Subject: Re: [PATCH] mshtml: When creating new channel default to current locale charset. Message-Id: Date: Tue, 23 Jun 2020 17:20:16 +0200 In-Reply-To: <20200622180811.d0aa8ca15e038ad19742f90c@baikal.ru> References: <20200619111913.b69c04677c2a5ddce60da412@baikal.ru> <20200622180811.d0aa8ca15e038ad19742f90c@baikal.ru> On 22.06.2020 12:08, Dmitry Timoshkov wrote: > Jacek Caban 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: > > > > > > > > and Wine's mshtml renders this file correctly. Main html includes another > file with the following 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 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