(*** This bug was imported into bugs.kde.org ***) Package: kjs Version: unknown (using KDE 2.2.1 ) Severity: normal Installed from: compiled sources Compiler: gcc version 2.95.3 20010315 (release) OS: SunOS (sun4u) release 5.6 OS/Compiler notes: If I go to the www.epinions.com only the title bar is visible altoguh by looking to the document source evertyhing is downloaded (but not rendered to the screen). By disabling javascript the page is rendered correctly. Andras PS: the "page not rendered" error happens also for some bug-reports (mainly the generated messages telling about closing a bug-report). I don't know if disabling javascript helps in that case or not bu next time when I experience the error I will check. (Submitted via bugs.kde.org) (Called from KBugReport dialog)
Only "Auto" tab is not rendered by KDE 2.2.2 and 3.0 Beta2.
*** Bug 44413 has been marked as a duplicate of this bug. ***
*** Bug 40233 has been marked as a duplicate of this bug. ***
Created attachment 140 [details] tescase Some of the epinions pages had <noscript> tags for the javascript generatet doubleclick-ads - with quotes(!). That might explain the javascript on/off difference.
Ok so it's not a javascript bug. Can anyone test the testcase in IE? Mozilla can't really be used as reference, it has many bugs.
Subject: Re: www.epinions.com not rendered (tokenizer problem with bad HTML) Do you mean see how IE renders the www.epinions.com? I can test anything you want with IE. Andras PS: I reported this bug some time in the past on Solaris, but a week ago I noticed the same thing on Linux and KDE HEAD. Netscape 6 didn't had any problem. On 2002. November 10., Sunday 22:06, 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=33902 > faure@kde.org changed: > > What |Removed |Added > --------------------------------------------------------------------------- >- Component|kjs |khtml > Summary|www.epinions.com not |www.epinions.com not > > |rendered with javascript |rendered (tokenizer > | problem enabled |with bad HTML) > > ------- Additional Comments From faure@kde.org 2002-11-10 21:06 ------- > Ok so it's not a javascript bug. > Can anyone test the testcase in IE? Mozilla can't really be used as > reference, it has many bugs.
IE 6 does render the "Mozilla does." part of the testcase, just like Mozilla. It's just Konqi that doesn't.
Works okay in CVS.
Hi, the problem appears again in 3.1.4 Disabling JS fixed it. Something is still wrong with with konq.
It doesn't happen in HEAD, and I see no JS errors either. We actually render the site far nicer than mozilla does.
Back again, not on the front page though, testcase still fails
*** Bug 71652 has been marked as a duplicate of this bug. ***
*** Bug 72455 has been marked as a duplicate of this bug. ***
Pages render properly with Javascript turned on using KDE 3.2.2.
The "Mozilla does"-portion of the testcase in comment #4 is not shown with HEAD.
Issue does not exist in the latest version of KDE / Konqueror (3.5.4 from source). Please close.
testcase #4 still fails (snv r457k)
Changing OS to Linux, as it fails on that as well as of today.
testcase #4 still fails in trunk
testcase in comment #4 still fails on svn trunk r790203
Confirmed in current trunk too... anyway, I'm still asking to myself, why a web developer should do something like that. -_-
Testcase fails in trunk.
SVN commit 1071706 by jtamate: BUG: 33902 follow html5 unquoted attribute sintax http://reviewboard.kde.org/r/1849/ M +4 -1 htmltokenizer.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1071706
This fix caused a regression: Images.google.com doesn't load image previews, e.g.: http://images.google.com/images?q=nasobem
Ouch, I see Maksim fixed it already, but I'm no longer much supportive of this patch... I thought I had tested the behaviour in Mozilla, but my test was bogus : it used the content css property, which isn't supported inside style attribute by Gecko, so the characters weren't actually stoping the attribute parsing as I thought :-( Retesting, I see even fairly modern Gecko doesn't in fact end the attribute for any of single quote, double quote, less-than or grave accent. Other UAs also allow single quote, double quote, less-than or grave accent. The potential for other breakage is really high, so it's probably wiser to just revert the rest of it. @Jaime: sorry about that, the only way to fix this bug then will be to fix parsing of attribute name <div ' > that's the real matter