Version: 4.0 (using KDE 3.1.2) Installed from: compiled sources Compiler: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) OS: Linux (i686) release 2.4.17 When connecting to an internal WebServer (webinterface to bug tracking system), I sometimes get in konqi the content it received (the javascript) in an embedded texteditor. This seems to be a timing problem, because when I redo the query, sometimes it then works as expected and I get the HTML page displayed. The chance to get the wrong display is higher if the resulting document is longer. One such received script was: <script type="text/javascript"> <!-- function isNetscape4() { if (navigator.appName == "Netscape") { if (navigator.appVersion.indexOf('4.') == 0) { return true; } } return false; } // Return true if the browser is based on a version of Mozilla // greater than 1.0 function isMozilla1() { if (navigator.appName != "Netscape") return false; if (navigator.appVersion.substring(0,3) < "5.0") return false; if (navigator.userAgent.indexOf('rv:0') != -1) return false; return true; } function refreshIfRequired() { if (isNetscape4()) { history.go(0); } } function goToCurrentIssue() { // On Mozilla 1.0+ setting the hash location in the onload causes // an infinite request loop if (!isMozilla1()) { document.location.hash="CurrentIssue"; } else { document.anchors['CurrentIssue'].scrollIntoView(); } } //--> </script> <html> <head> <link rel="stylesheet" type="text/css" href="/is.css" /> <link rel="stylesheet" type="text/css" href="/imweb/im.css" /> </head> <body onresize="refreshIfRequired()" onload="goToCurrentIssue()"> <form onsubmit="return onSubmit();" action="/im?WebLogicSession=PxuYpkWLN8sWbHDBsBYvRVb8lPkz4Ki2nKL4pZQdItjMHbAYmNRa|-5095635783160447937/-1062693162/6/9001/9001/7002/7002/9001/-1&mks.commandRunner=5805" target="_top" method="POST"> <script type="text/javascript"> <!-- function doSubmit(action, targetPage, inputPage, preCondition) { if (checkPageLoaded(inputPage) == false) { return; } if (inputPage != null && inputPage != window.name) { doRemoteSubmit(action, targetPage, inputPage, preCondition); } else { if (preCondition != null) { var success = eval(preCondition); if (success == false) { return; } } document.forms[0].proxyRender.name = null; document.forms[0].proxyRender.value = null; if (targetPage == null) { targetPage = "_top"; } if (targetPage.substr(0,1) != "_") { document.forms[0].proxyRender.name = "mks.render"; document.forms[0].proxyRender.value = targetPage; } document.forms[0].target = targetPage; document.forms[0].proxySubmit.name = "mks.action"; document.forms[0].proxySubmit.value = action; document.forms[0].submit(); } } // Returns true if the inputPage page is loaded, otherwise alert the user // and return false function checkPageLoaded(inputPage) { var isPageLoaded = true; if (inputPage != null) { if (top.frames[inputPage].pageLoaded == null) { isPageLoaded = false; } } else { if (this.pageLoaded == null) { isPageLoaded = false; } } if (!isPageLoaded) { alert('Please wait for the page to finish loading.'); } return isPageLoaded; } function onSubmit() { // If a web action has not been specified, don't proceed with the submit if (document.forms[0].proxySubmit.value == "") { return false; } return true; } function doRemoteSubmit(action, targetPage, inputPage, preCondition) { top.frames[inputPage].doSubmit(action, targetPage, null, preCondition); } function invokeMenuItemHandler(menu, handlerArray) { var i = menu.selectedIndex - 1; if (i >= 0) { eval(handlerArray[i]); } menu.selectedIndex = 0; } function evalOnSelect(select, handlerArray) { var i = select.selectedIndex; var result = true; if (i >= 0) { var handler = handlerArray[i]; if (handler != null) { result = eval(handler); if (result == null) { result = true; } } } return result; } function doPanelSelect(action, panel, target) { document.forms[0].mks_selectedPanel.value = panel; doSubmit(action, target); } var heartbeatTimer = null function stopHeartbeat() { clearTimeout(heartbeatTimer) } function startHeartbeat(seconds,heartbeat) { heartbeatTimer = setTimeout(heartbeat,seconds * 1000) } //--> </script> <input type="hidden" name="proxySubmit" value=""> <input type="hidden" name="proxyRender" value=""> <input type="hidden" name="mks_selectedPanel" value=""> <table class="ViewPanel" border="0" cellspacing="0" cellpadding="0" width="100%"> <tr> <td> <input type="hidden" name="mks_issue_index" value=""> <input type="hidden" name="mks_sort_field" value=""> <script type="text/javascript"> <!-- function singleIssueSelection() { if (issueCnt != 1) { alert('Please select exactly one issue.'); return false; } return true; } function nonEmptyIssueSelection() { if (issueCnt == 0) { alert('Please select at least one issue.'); return false; } return true; } //--> </script> <script type="text/javascript"> <!-- function doSelectIssue(issue) { document.forms[0].mks_issue_index.value = issue; doSubmit('selectIssue'); } function doSort(field) { document.forms[0].mks_sort_field.value = field; doSubmit('sort'); } //--> </script> <table cellspacing="0" cellpadding="0" border="1" width="100%"> <tr> <td width="100%"> <a NAME="CurrentIssue"></a> <script type="text/javascript"> <!-- function toggleSelection(selectionParam) { if (document.forms[0].toggleAll.checked) { selectAll(selectionParam); } if (!document.forms[0].toggleAll.checked) { selectNone(selectionParam); } } function selectAll(selectionParam) { for (var i=0;i<document.forms[0].elements.length;i++) { if (document.forms[0].elements[i].name==selectionParam) { if (document.forms[0].elements[i].checked == false) { document.forms[0].elements[i].click(); } } } } function selectNone(selectionParam) { for (var i=0;i<document.forms[0].elements.length;i++) { if (document.forms[0].elements[i].name==selectionParam) { if (document.forms[0].elements[i].checked == true) { document.forms[0].elements[i].click(); } } } } function checkboxCount(row, counter) { if (row.checked == true) { counter = counter + 1; } else { counter = counter - 1; } return counter; } function radioCount(row, counter) { resetCounters(); counter = 1; return counter; } //--> </script> <table border="0" width="100%" cellspacing="1" cellpadding="3"><tr><td NOWRAP width="1%" class="HeaderRow"><input onclick="javascript:toggleSelection('mks_table_selection');" name="toggleAll" type="checkbox"></td><td NOWRAP class="HeaderRow"><a onMouseOut="window.status='';return true" href="javascript:changeSortOrder();" onclick="javascript:doSort('-5'); return false;" onMouseOver="window.status='Change Sort Order';return true" title="Change Sort Order">ID</a> <a onMouseOut="window.status='';return true" href="" onclick="javascript:doSort('-5'); return false;" onMouseOver="window.status='Invert Sort Order';return true" title="Invert Sort Order"><img border="0" alt="Invert Sort Order" src="/imweb/images/SortDown.gif"/></a></td> <td NOWRAP class="HeaderRow"><a onMouseOut="window.status='';return true" href="javascript:changeSortOrder();" onclick="javascript:doSort('9'); return false;" onMouseOver="window.status='Change Sort Order';return true" title="Change Sort Order">oldId</a></td> <td NOWRAP class="HeaderRow"><a onMouseOut="window.status='';return true" href="javascript:changeSortOrder();" onclick="javascript:doSort('-11'); return false;" onMouseOver="window.status='Change Sort Order';return true" title="Change Sort Order">Type</a></td> <td NOWRAP class="HeaderRow"><a onMouseOut="window.status='';return true" href="javascript:changeSortOrder();" onclick="javascript:doSort('-10'); return false;" onMouseOver="window.status='Change Sort Order';return true" title="Change Sort Order">Summary</a></td> <td NOWRAP class="HeaderRow"><a onMouseOut="window.status='';return true" href="javascript:changeSortOrder();" onclick="javascript:doSort('-9'); return false;" onMouseOver="window.status='Change Sort Order';return true" title="Change Sort Order">State</a></td> <td NOWRAP class="HeaderRow"><a onMouseOut="window.status='';return true" href="javascript:changeSortOrder();" onclick="javascript:doSort('-7'); return false;" onMouseOver="window.status='Change Sort Order';return true" title="Change Sort Order">Assigned User</a></td> <td NOWRAP class="HeaderRow"><a onMouseOut="window.status='';return true" href="javascript:changeSortOrder();" onclick="javascript:doSort('-8'); return false;" onMouseOver="window.status='Change Sort Order';return true" title="Change Sort Order">Project</a></td> <td NOWRAP class="HeaderRow"><a onMouseOut="window.status='';return true" href="javascript:changeSortOrder();" onclick="javascript:doSort('11'); return false;" onMouseOver="window.status='Change Sort Order';return true" title="Change Sort Order">Scheduled for</a></td></tr><tr><td NOWRAP width="1%" class="HighlightedRow"><input name="mks_table_selection" onclick="issueCnt=checkboxCount(this,issueCnt);" type="checkbox" value="0"></td> <td NOWRAP class="HighlightedRow"><a onMouseOut="window.status='';return true" href="javascript:selectIssue();" onclick="javascript:doSelectIssue('0'); return false;" onMouseOver="window.status='View Issue';return true" class="ViewIssueIDLink" title="View Issue">50935</a></td> <td NOWRAP class="HighlightedRow"><a href="javascript:selectIssue();" onclick="javascript:doSelectIssue('0'); return false;" class="ViewIssueLink">0</a></td> <td NOWRAP class="HighlightedRow"><a href="javascript:selectIssue();" onclick="javascript:doSelectIssue('0'); return false;" class="ViewIssueLink">Problem</a></td> <td class="HighlightedRow"><a href="javascript:selectIssue();" onclick="javascript:doSelectIssue('0'); return false;" class="ViewIssueLink">Tabelle - Fontattribute pro Zeile</a></td> <td NOWRAP class="HighlightedRow"><a href="javascript:selectIssue();" onclick="javascript:doSelectIssue('0'); return false;" class="ViewIssueLink">AUFG ENTW</a></td> <td NOWRAP class="HighlightedRow"><a href="javascript:selectIssue();" onclick="javascript:doSelectIssue('0'); return false;" class="ViewIssueLink">ivok</a></td> <td NOWRAP class="HighlightedRow"><a href="javascript:selectIssue();" onclick="javascript:doSelectIssue('0'); return false;" class="ViewIssueLink">\PVSS_II</a></td> <td NOWRAP class="HighlightedRow"><a href="javascript:selectIssue();" onclick="javascript:doSelectIssue('0'); return false;" class="ViewIssueLink">3.0 PreBeta</a></td></tr></table><script type="text/javascript"><!-- var issueCnt = 0; //--></script><script type="text/javascript"><!-- function resetCounters() { issueCnt = 0; } //--></script> </td> </tr> </table> </td> </tr> </table> </form> </body> <script type="text/javascript"> // A function that can be interogated to determine if the current document has // completed loading. Currently done from submit(). function pageLoaded(){} </script> </html>
konqueror checks for two things: * the mimetype transmited by the web server (not always present) * for HTML tags in the header As your HTML is invalid in starting with <script> the second one doesn't find any, so I guess your web server is misconfigured to not emit a mimetype.
Subject: Re: konqi sometimes displays javascript in texteditor instead of execute it On Wednesday 22 October 2003 13:30, you wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=61483 > coolo@kde.org changed: > > What |Removed |Added > --------------------------------------------------------------------------- >- Status|UNCONFIRMED |RESOLVED > Resolution| |WONTFIX > > > > ------- Additional Comments From coolo@kde.org 2003-10-22 13:30 ------- > konqueror checks for two things: > * the mimetype transmited by the web server (not always present) > * for HTML tags in the header > > As your HTML is invalid in starting with <script> the second one > doesn't find any, so I guess your web server is misconfigured to not > emit a mimetype. I'm wondering why the same query does sometimes result in a correctly displayed page then. For me this seems like a timing problem. Is that possible ? As I'm getting this HTML page from a Webserver which is part of a bug tracking system, I can not change the server. This server is used by a lot of my colleagues with MS-IE and they don't see this problem. Also, if I'm browsing with Netscape I don't have this problem. The content I gave in on bugs.kde.org is in fact the part of the page (the frame) which is shown instead of a HTML list. Maybe I gave too less information for you to check what's wrong in konqi ?
Well, I doubt there is something wrong in konqueror. It just can't cope with the things that are wrong in your system :) BTW: there is some very simliliar bug to yours: #64753
Subject: Re: konqi sometimes displays javascript in texteditor instead of execute it On Wednesday 22 October 2003 14:31, you wrote: > ------- Additional Comments From coolo@kde.org 2003-10-22 14:31 ------- > Well, I doubt there is something wrong in konqueror. It just can't cope > with the things that are wrong in your system :) Even if there is something wrong with the companies bug tracking system, the fact is, that konqueror sometimes can not display the content but MS-IE and Netscape can. As I like to use konqueror, I would also like to help to find the bug - or if you like - make konqi more fault tolerant. Still it is not clear if that is a bug in the content, because as I explained already: _sometimes_ it works. In detail: if it does not work, I get for a short amount of time a "Copy File in progess" Dialog. If it works, I don't get the dialog. > BTW: there is some very simliliar bug to yours: #64753 It seems, that this one is slightly different in the way that it never works for him.
Can you comment on the fact, that it _sometimes_ works ?
I have tested this bug with KDE 3.3.2a and I can't reproduce it. I have extracted the code out of the bug report and have copied it into a test.html file and opened it local with my Konqueror. Konqueror executes everytime the Script and renders it so I never saw the plain JavaScript code. Then I copied it on my webserver (Apache 1.3) and I loaded it with my browser. Again rendering was never a problem (I tried it several times). Note: The transmitted content type of my Apache was text/html. Then I changed the file from "test.html" to "test" and now it always showed the plain code (the transmitted mime type was text/plain). The same bevahior was shown by Mozilla 1.4. So really no surprise. Since the URL you have experienced this problem will be something dynamical generated, one can suppose that Mozilla and IE have some smart URL content guessing, but without the exact URL this is pure speculation. So since this bug can't be reproduced I think it should be closed.
I'm sorry to say that the bug is still present in KDE 3.4, so please don't close it. But maybe you can give me an additional hint: Why is this done only _sometimes_ ? It seems to be a timing problem. As I can reproduce it easily (when I'm at the company), how can I help to find the bug ?
Hm try the following: *Go on that page with Konqueror and then look in the Konqueror menu in "view -> document information" (or something like that, I'm translating backwards from German, where it is called "Ansicht -> Documentinformation anzeigen") *Then look in the box what "conten type" shows. *If it displays "text/html" everytime (also when the bug occours) then your webserver is likely correctly configured. Maybe it shows only sometimes this content type and sometimes not? Can you paste the URL for testing? If not: Maybe only the string after the Domain name. Is the URL always the same?
What I get if it does not work, is first a Dialog, asking: "Open 'http://eis2k214:90...ender=QueryResults'? Type: Objective-C Source File" Objective-C ?? I click open and see then the java source. Looking then into the Document Information Dialog, there is _no_ Content type. The only things I see are in the general section: Title, URL, Document encoding (The table HTTP Headers is empty) The URL I used was: http://eis2k214:9001/im?WebLogicSession=QiQanenpL2XvlNlM1NyvB77wtYv8gaMA5932JOCnsXDvCCt86vRu|-6364945919724719754/-1062693162/6/9001/9001/7002/7002/9001/-1&mks.commandRunner=1949 Doing it a second time, using URL (only difference I see is the commandRunner) http://eis2k214:9001/im?WebLogicSession=QiQanenpL2XvlNlM1NyvB77wtYv8gaMA5932JOCnsXDvCCt86vRu|-6364945919724719754/-1062693162/6/9001/9001/7002/7002/9001/-1&mks.commandRunner=1950 it works and I see the content. Looking at the Document Information Dialog I see the same as before (no content type, no HTTP headers entry) (I should mention that the page is a frameset). Comparing the javascript source with the html frame source when it works reveals no difference (so it's not the content but something else ...) Sniffing the transfer with ethereal shows, that the webserver does not send a Content-Type header (still, konqi did display it correctly this time). e.g. HTTP/1.1 200 OK Server: WebLogic 5.1.0 Service Pack 13 12/12/2002 22:13:10 #228577 Expires: -1 Cache-Control: no-cache Connection: Close <script type="text/javascript"> <!-- function isNetscape4() { <snip>
Hm okay this shows clearly that it is a bug in your server software/configuration. Mozilla and IE seem to have some more clever logic inside to detect this as HTML/JavaScript-Code and so this bug doesn't occour on these browsers. So although it is not Konquerors fault here we need some workaround (as I assume, that this ist not the only page showing such a bug). Can you paste an experpt of the relevant frame source which calls the JavaScript/HTML-file? Although I'm quite sure that it has nothing to do with that this would be the last point where there might could be a bug inside Konqueror. Anyhow as the document starts with '<script type="text/javascript">' which is a XML-tag I would suggest that those files with such tags are treated as HTML/XML by default and get rendered as pure JavaScript files don't have such a XML header and have a file extension called ".js" Although I can't explain to me, why it sometimes functions and why not, I guess that this server bug would have been worked around with this. In parallel I would suggest to you (if you haven't done it already) to point your server administrator to this problem so that he can look wether it is a configuration problem or a problem in a software component (most likely the web server software) so that those guys can also get a bug report that there is something going wrong with their software...
On Tuesday 01 March 2005 13:38, Daniel Arnold wrote: > Hm okay this shows clearly that it is a bug in your server > software/configuration. Absolutely. We have already sent the producer company a bug report (a year ago ...) but the bug is still there :-( > Can you paste an experpt of the relevant frame source which calls the > JavaScript/HTML-file? Although I'm quite sure that it has nothing to do > with that this would be the last point where there might could be a bug > inside Konqueror. Don't know if the following helps: There is somewhere a call to "doSubmit('runCurrentQuery',null,null,null);" and the function is function doSubmit(action, targetPage, inputPage, preCondition) { if (checkPageLoaded(inputPage) == false) { return; } if (inputPage != null && inputPage != window.name) { doRemoteSubmit(action, targetPage, inputPage, preCondition); } else { if (preCondition != null) { var success = eval(preCondition); if (success == false) { return; } } document.forms[0].proxyRender.name = null; document.forms[0].proxyRender.value = null; if (targetPage == null) { targetPage = "_top"; } if (targetPage.substr(0,1) != "_") { document.forms[0].proxyRender.name = "mks.render"; document.forms[0].proxyRender.value = targetPage; } document.forms[0].target = targetPage; document.forms[0].proxySubmit.name = "mks.action"; document.forms[0].proxySubmit.value = action; document.forms[0].submit(); } } // Returns true if the inputPage page is loaded, otherwise alert the user // and return false function checkPageLoaded(inputPage) { var isPageLoaded = true; if (inputPage != null) { if (top.frames[inputPage].pageLoaded == null) { isPageLoaded = false; } } else { if (this.pageLoaded == null) { isPageLoaded = false; } } if (!isPageLoaded) { alert('Please wait for the page to finish loading.'); } return isPageLoaded; } function onSubmit() { // If a web action has not been specified, don't proceed with the submit if (document.forms[0].proxySubmit.value == "") { return false; } return true; } function doRemoteSubmit(action, targetPage, inputPage, preCondition) { top.frames[inputPage].doSubmit(action, targetPage, null, preCondition); }
Is the "bug" reproducable with kde 3.5.4, has a workaround been applied?
The bug is still there in KDE-3.5.5. ( In fact it got even worse as it seems that the java script handling did change somehow and I get additional other strange behaviour. ) As I can not use konqueror due to that, I run firefox for this bugtracking system. So If you can't do anything, you can close this bug.
using konqueror 3.5.5 1. saved comment #1 code snippet in a file test.html 2. open it in konqueror ==> i get a valid webpage 3. rename test.html to test 4. open it in konqueror ==> i get a valid webpage so it seems to me that the bug has been corrected.
No, the bug is still there (tested with current svn 3.5.5 head). As described, the problem seems to be a timing issue, as it does not happen always. The test with using a local file does not reflect the situation where the problem occurs.
I tested doing the following: I have Apache 2.2.3 running on port 80 at localhost. Apache determines mime types via file extension. I had a hard time trying to disable this functionality without borking Apache completely, so instead I removed the file extensions so that Apache sends Content-Type: text/plain. I used Wireshark to monitor the HTTP transmissions. I used three test files: test - your script as copied from your original post. test2 - your script altered to structure the document properly. test3.html - the original script with correct filename. Both test and test2 open in KWrite. Oddly enough, in both cases, a second GET /test after the first has been successfully retrieved. In the case of test3.html, the Content-Type is text/html and the page renders successfully. Konqueror has an uncanny ability to detect mime-types for files without an extension, so it appears that it simply is not second-guessing the Content-Type it is sent. I changed the default mime type Apache returns to application/x-gzip (I can't seem to change it to nothing) and Konqueror brings up a dialog asking if I want to extract it. I can't test this, but it would appear in your case that Konqueror is defaulting to text/plain instead of checking the file first. The solution is to apply whatever routine Konqueror uses for determining the mime-type of local files to incoming HTTP files. This behaviour could either override Content-Type completely or only when Content-Type is invalid.
Sorry for spamming in three commits what should have been one, but I keep forgetting the little things :D I'm running KDE/Konqueror 3.5.5 on Kubuntu Edgy
I seem to be getting something similar to this. It's really annoying as it happens on all sorts of webpages on the internet, over which I obviously exercise no control. I'll go to a site ( http://digg.com/pc_games/First_details_of_Call_of_Duty_4 for example) and a dialog (or two, more on other sites) will popup. Text being "Open http://somesite? Type: Plain Text Document" See screeny: http://img501.imageshack.us/my.php?image=dialog1qb7.png If I choose to open, the script is displayed. If cancel, the area it would have displayed is blank. see second screeny if you wish: http://img142.imageshack.us/my.php?image=dialog2ex3.png I'm not sure if this is the same bug; I only seem to be noticing it since 3.5.7. Symptoms seem similar anyway. At any rate it is very annoying to have to close dialogs for seemingly every other page. I could click "remember this action" but I'd rather not. There are actually legitimate text files on the internet, some of which I'd like to open or save. If this would qualify as a new bug, please let me know :)
Re: comment #18, it may or may not be the same bug, but it's probably best if you file a separate bug report, since your report is very concrete and about a popular website and hence would be easier to fix, as it e.g. doesn't require installing apache or such!)
7.2.1, RFC 2606: "If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".
OK, actually it -does- try to guess the mimetype from content...
OK, basically, what happens is that it doesn't find enough evidence to consider the document html (all it sees is one common tag, and that's it). I could probably tweak it for the digg example, but there is no guarantee that wouldt help for the larger files where there is mostly JS and not much html in the first kb or so, and might not help in other instances.. KDE4 has different mimecode, so may be it'll be a bit more robust with this, will test. Of course, if servers only followed the SHOULD saying to send content-type nothing like this would happen...
SVN commit 675285 by dfaure: Add check for shared-mime-info fix requested by Maksim CCBUG: 61483 M +7 -0 kmimetypetest.cpp --- trunk/KDE/kdelibs/kdecore/tests/kmimetypetest.cpp #675284:675285 @@ -290,6 +290,13 @@ QVERIFY( mime ); QCOMPARE( mime->name(), QString::fromLatin1("text/plain") ); +#if 0 // https://bugs.freedesktop.org/show_bug.cgi?id=11259 + QByteArray htmlData = "<script>foo</script>"; + mime = KMimeType::findByContent(htmlData); + QVERIFY( mime ); + QCOMPARE( mime->name(), QString::fromLatin1("text/html") ); +#endif + QByteArray pdfData = "%PDF-"; mime = KMimeType::findByContent(pdfData); QVERIFY( mime );
SVN commit 675314 by orlovich: Be a bit more trusting of some tags when trying to autodetect the mimetype... ... which not uncommonly happens due to sucky servers (Common with ads -- there are some on digg.com, sports.yahoo.com...) CCBUG:61483 M +8 -5 kmimemagic.cpp --- branches/KDE/3.5/kdelibs/kio/kio/kmimemagic.cpp #675313:675314 @@ -230,6 +230,9 @@ #define L_DIFF 0x400 /* Output of diff */ #define L_OBJC 0x800 /* Objective C */ +// Note: this is not a type, it's just used to mark items that should count more +#define FLAG_STRONG 0x1000 + #define P_HTML 0 /* HTML */ #define P_C 1 /* first and foremost on UNIX */ #define P_MAKE 2 /* Makefiles */ @@ -271,10 +274,10 @@ short type; } const names[] = { { - "<html", L_HTML + "<html", L_HTML | FLAG_STRONG }, { - "<HTML", L_HTML + "<HTML", L_HTML | FLAG_STRONG }, { "<head", L_HTML @@ -340,10 +343,10 @@ "<FRAMESET", L_HTML }, { - "<script", L_HTML + "<script", L_HTML | FLAG_STRONG }, { - "<SCRIPT", L_HTML + "<SCRIPT", L_HTML | FLAG_STRONG }, { "/*", L_C|L_CPP|L_JAVA|L_OBJC @@ -1881,7 +1884,7 @@ } } for (i = 0; i < (int)NTYPES; i++) { - if ((1 << i) & p->type) typecount[i]++; + if ((1 << i) & p->type) typecount[i]+= p->type & FLAG_STRONG ? 2 : 1; } } }
This seems to be fixed based on the last two comments. Feel free to reopen this ticket if the issue is still present in the most recent KDE release, v4.6 and up.