Version: (using KDE 4.3.4) OS: Linux Installed from: Debian testing/unstable Packages Hi, a sample page not displaying properly is http://www.vmware.com/support/server2/doc/releasenotes_vmserver202.html it's full of overlapping text. Will attach a screenshot. Thanks, Andrea.
Created attachment 40454 [details] screenshoot
hmm, indeed. I see the same in branch and trunk. 4.2.4 displays the site fine... would anyone be able to test with some 4.3 branch build?
oh, sorry, I missed that you are using 4.3.4... so that would be a quite old regression already.
Created attachment 40532 [details] snapshoot version 4.1.2 Tested version 4.1.2 and seems the bug was already present. (see attached snapshoot). I strongly suspect the breaking revision is r724766, but can't say for sure... Will try to go deeper.
Created attachment 40607 [details] test patch - revert r724766 I tried to manually revert r724766 (on khtml 4.3.4) and the page displays fine... For clarity attached the patch i used. HTH, Andrea
thank you for the nice hint. Still, the page works fine in 4.2.4, so some other modifications in-between likely un-broke, then broke it again, but likely fixed other problems. That's the typical game in parsing, where the behaviour of other browsers is really hard to figure out deterministically - and HTML5 wanting to cast "reality" in stone usually only manages to create yet another set of weird conditions that matches no other engine and doesn't even have logic as a basis ;-/ I suspect #227109 that just got reported is a duplicate. It similarly works fine in 4.2.4. Might be easier to get a reduction there.
while applying (reverting) patch of c#5 fixes vmware page, site on bug #227109 (www.directon.com) is not fixed at all. Strange thing is that saving a local copy of www.directon.com with FF (3.5.6) then opening with konqueror works, while a local copy of vmware page is still not working.
ah, so different issue then, sorry. (As for the saved copy working, it just means the content served to mozilla is different based on browser sniffing, possibly server side. Making the archive with the konq plugin war archiver does show the error, and so does an archive made with "wget -EHpkx http://www.directron.com" )
Archive made by konqueror looks buggy as the on-line site. Saved copy made by wget looks buggy in Konq (with some additional js parse error compare to the on line version), looks fine on FF.
Germain, i found the cause of bug about http://www.directron.com , added comments here -> bug #227109
Found the problem is caused by <LI> tags (Doesn't have a tescase atm, sorry) That's regressed by r724766 where following changes, in html/htmlparser.cpp and html/dtd.cpp, involved ID_LI : html/htmlparser.cpp @@ -988,7 +985,7 @@ n = new HTMLMenuElementImpl(document); break; case ID_LI: - popBlock(ID_LI); + popOptionalBlock(ID_LI); n = new HTMLLIElementImpl(document); break; // formatting elements (block) html/dtd.cpp @@ -105,10 +103,10 @@ 1, // ID_LABEL 1, // ID_LAYER 1, // ID_LEGEND - 3, // ID_LI + 5, // ID_LI 0, // ID_LINK 1, // ID_MAP - 3, // ID_MARQUEE + 5, // ID_MARQUEE 5, // ID_MENU 0, // ID_META 5, // ID_NOBR I just tried to revert html/dtd.cpp ID_LI part, that is i modified line 5, // ID_LI to 3, // ID_LI and the bug has gone. (Tested with KDE 4.4.5) Hope this help.
Created attachment 53112 [details] testcase
Created attachment 56946 [details] proposed patch this patch fix the problem for me, but i'm not sure if it's safe to commit
Confirmed on kde 4.6
*** This bug has been marked as a duplicate of bug 182164 ***