Bug 133099 - KHTML: some web pages which rendered fine in 3.5.3 not working in 3.5.4
Summary: KHTML: some web pages which rendered fine in 3.5.3 not working in 3.5.4
Status: RESOLVED DUPLICATE of bug 130689
Alias: None
Product: konqueror
Classification: Applications
Component: khtml renderer (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-27 23:55 UTC by Ivan Crespo
Modified: 2007-05-23 15:40 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Offending HTML and screen capture (82.70 KB, application/zip)
2006-09-27 19:55 UTC, Ivan Crespo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Crespo 2006-08-27 23:55:07 UTC
Version:           3.5.4 (using KDE 3.5.4, Kubuntu Package 4:3.5.4-0ubuntu1~dapper1 )
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.15-23

Hi,

I just downloaded KDE 3.5.4. and installed it on my Kubuntu/Dapper box. While I must say I'm delighted with the speediness and overall polish of this release, I have observed some "involution" in the rendering acuracy of Konqueror/KHTML. Certain javascript/CSS-laden pages which used to render just fine in 3.5.3 now fail under 3.5.4.

This is the one that most annoys me (it is my bank's page, used by millions of Spaniards daily).

   https://oi.cajamadrid.es

Unfortunatelly, the bug appears ONCE you're logged on; I cannot post my access credentials here, sorry :).

Once you're in, there is a neat systems of javascript menus which dynamically update the central area of the page. The problem is that this central area doesn't show up anymore in Konqueror. (actually it does show up during a split second -the time it takes Konqueror to finish loading the page- then it disappears).

I I haven't installed any plugins yet, other than Flash. I downloaded the .deb packages for Kubuntu from ftp.kde.org.

Hope you can fix this one. Please, let me know if I can be of any further help to you.

Thanks in advance.

Ivan Crespo
Comment 1 Charles Samuels 2006-09-27 18:36:41 UTC
I'm afraid that you'll have to make us a test case.
Comment 2 Ivan Crespo 2006-09-27 19:55:06 UTC
Created attachment 17946 [details]
Offending HTML and screen capture

Hi again, and thanks for following up!

I'm attaching an example of the offending HTML/CSS stylesheet and a screen
capture of how this looks like in a Mozilla-based browser (Camino). It renders
pretty similarly in Apple's Safari, just as it did in pre-2.5.4 releases of
Konqueror.

Cheers,

Ivan.
Comment 3 Maksim Orlovich 2006-09-27 21:21:08 UTC
Allan: the stylesheet has the following:
body:last-child .clearfix {content:".";}

And the element with the clearfix has that id.
Might be worth disabling this support for now, no?

(Piece of stylesheet, for context:
/* clearfix corregido opera */
.clearfix:after { content: "";display:block; clear:both; height:0; visibility:hidden;}
body:last-child .clearfix {content:".";}
.clearfix {display:inline-block;}
/* \*/
* html .clearfix {height:1%;} 
)


Comment 4 Maksim Orlovich 2006-09-27 21:23:35 UTC
To reporter: thanks, that was sufficient. Basically, we support a CSS3 feature in 3.5.4 most other browsers don't, and it ends up breaking this website --- they have a CSS rule saying to replace the content of that important box with "."...


Comment 5 Allan Sandfeld 2006-09-27 23:14:21 UTC
But why?? Why are they using that rule... 

I guess content on normal elements should only be accessed through ::-khtml-replace
Comment 6 Allan Sandfeld 2007-05-23 15:40:25 UTC

*** This bug has been marked as a duplicate of 130689 ***