[PATCH] Possible solution to fix #68747 and #66103
Andras Mantia
amantia at kde.org
Thu Dec 4 14:41:35 GMT 2003
Dirk Mueller wrote:
> On Tuesday 02 December 2003 13:40, Andras Mantia wrote:
>
>> Currently KHTML stops parsing the <head> </head> tag area for encoding
>> information if an unexpected/invalid tag is found prior of <head> or
>> inside <head></head>. This results in not detecting the correct encoding
>> in those (broken) files.
>
> which broken files?
See the bugreport #68747. Basicly the encoding search is abandoned if an
unexpected tag is before <head> or inside <head></head> before the <meta> tag
that contains the encoding information.
>> The only drawback I can see is that parsing such pages becomes somewhat
>> slower.
>
> "somewhat" is a good one. it will delay parsing and rendering of the whole
> page until it is completely received in almost all cases now. Thats not
> acceptable.
Also when the </head> is present? As far as I can see the search is ended as
soon as one of the following is found:
case ID_SCRIPT:
case (ID_SCRIPT+ID_CLOSE_TAG):
case ID_NOSCRIPT:
case (ID_NOSCRIPT+ID_CLOSE_TAG):
case ID_STYLE:
case (ID_STYLE+ID_CLOSE_TAG):
case ID_LINK:
case (ID_LINK+ID_CLOSE_TAG):
case ID_OBJECT:
case (ID_OBJECT+ID_CLOSE_TAG):
case ID_TITLE:
case (ID_TITLE+ID_CLOSE_TAG):
case ID_BASE:
case (ID_BASE+ID_CLOSE_TAG):
case ID_HTML:
case ID_HEAD:
case 0:
case (0 + ID_CLOSE_TAG ):
break;
The full document search will be done only when none of the above is true and
the encoding was not found in a <meta> tag. Of course, if I didn't
misunderstand the code.
I didn't profile, but there was no visual slowness here.
Andras
--
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org
--
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org
More information about the kfm-devel
mailing list