Version: 4.0 (using KDE 3.1.3) Installed from: SuSE Compiler: gcc version 3.3 20030226 (prerelease) (SuSE Linux) OS: Linux (i686) release 2.4.20-4GB http://texturizer.net/firebird/index2.html passes the XHTML 1.0 STRICT test at W3C. Mozilla Firebird 6.1+ renders the page showing news items and additional news items. Konqueror does not show any news items and when clicking "additional news items" does not show any articles.
I now consider this bug CRITICAL - LOSS OF DATA
"LOSS OF DATA"? What a ridiculous reasoning in this case to get CRITICAL bug state.
Created attachment 2953 [details] Testcase
This is actually a javascript bug, nothing to do with XHTML or rendering. Referenced functions (probably variables too) from included javascript files (from script src= tags) are not correctly found. Testcase works in moz, opera, iE
The JS file is in fact in UTF-16. So the parse error is due to wrong decoding of the file. Not sure if it's kjs or khtml's loader that's supposed to detect the encoding of external JS files... Harri? Dirk?
kjs has a ucs-2 interface. It would sounds strange to me pass the data in a 16-bit format only to later discover that its UTF-8 or UTF-16 and expand or shrink it again. The only place in kjs that would be suitable for a detection would be testkjs.cpp which is not part of kjs proper. As khtml/kio are the ones being fed data in byte format I suggest to do the decoding there. Unless we realize that e.g. KHTMLPart::write(const QString&) has to detect non-UCS-2 formats, too. Which I doubt.
*** Bug 69115 has been marked as a duplicate of this bug. ***
As far as I can tell this is an Apache Mod-Rewrite issue that is being triggered by a difference in the HTTP headers that Konqueror hands over, as compared to other browsers. More on that in a sec. The site works perfectly when run locally, but also when run from my own Apache host on the Internet. The minimum required changes to get the site working was to copy exact replicas of the files (news.html, loadNews.js, & newsSetup.js) to my own host, modifying news.html to use the two scripts on my host while forcing it (absolute links) to continue using the remaining style sheets and scripts from the original host. You can see a working version of the news page here: <http://www.enkasa.com/firebird/news2.html> The problem _seems_ to be Mod-Rewrite related since the following two javascript URLs get externally re-directed before the file can be accessed on Konqueror, but do not do this on Mozilla. <http://texturizer.net/firebird/javascript/loadNews.js> <http://texturizer.net/firebird/javascript/newsSetup.js> The files are available from the redirected URL, but I suspect that Konqueror does not appreciate being re-directed for JavaScript includes. I do not have a debugging HTTP proxy server, but I imagine that differences in the HTTP cause the different paths through Mod-Rewrite.
I just noticed that if you click directly on the URLs you won't see the redirect problem. Do "Copy Link Location" instead and paste them into the address bar.
This seems to be fixed in KDE 3.2, or am I wrong?
No, you are right; the news is now correctly displayed in KDE 3.2. However there are two remaining problems still with the page: 1. the left-hand side links run down the page when you hover your mouse over them 2. there is an alignment problem with the left-hand side links and page content overlapping slightly I just did a reduction for the first problem. See below:
Created attachment 5023 [details] test case for falling link problem This test case shows a problem that occurs for block elements that have a hover rule (anything) and a content insertion rule that uses a particular character. The character looks like a space or a tab, but it is neither, and I don't know how to determine what the character is. Does anyone know how to do this without writing a program? So it looks like the content insertion rule is applied each time the hover rule is applied.
Although the "news" is now showing in KDE322, it looks like the css stylesheet that Texturizer is using contains invalid code. I sent them a note with the W3C Validator results attached.