(*** This bug was imported into bugs.kde.org ***) Package: konqueror Version: 2.0 Severity: normal Installed from: Mandrake 7.2 RPMs The flash plugin misaligns itself [ie is a few pixels off the bottom of the window] on certain sites. Most notably www.xdude.com where on a 1024 x 768 screen the large [full-screen] movie has the bottom 2 centimeters cut off by the bottom of the window. In Linux Netscape 4.76 it runs vertically centered. I believe it may be the full screen nature or the unusually large size of the movie that makes the effect occur on this site and not others. Thanks for your time and a wonderful desktop. (submitted via bugs.kde.org)
The original bug is fixed in HEAD (don't know for how long), but the pages show a pretty smal table-rendering buglet. Basically, on the attached testcase, the vertical position (centering) isn't re-calculated when the window is expanded vertically. When shrinking, it re-calculates the position only when it gets smaller than when it last re-calculated - i.e. the original calculation, or the last time is got smaller than that. <table width="100%" height="100%"> <tr> <td width="100%"><p align="center"> Some text goes here </tr> </table>
This bug should maybe be marked as closed? :-)
Created attachment 4296 [details] Test Case This bug still occurs in KDE 3.1.4, though it may be fixed 3.2, so I thought I'd make the above test case a link for easier checking.
Just tested in KDE 3.2 RC1 and the behaviour has changed completely, but the bug essentialy still remains. Now, it is even more complex: Re-centering still only occurs when the window is made smaller (as before), *but* the window must now _also_ be made bigger than the previous centering (opposite of previous behaviour), or the re-centering will not occur. Yes, this sounds like a paradox! Here are the steps to replicate: 1. open the test case 2. make the window much bigger (vertically) 3. now make the window a tiny bit smaller (again, vertically) The re-size occurs at step 3, but under no other conditions.
I can not reproduce this with KDE CVS ( 5 Apr. 2004 ) using the provided testcase. Can anyone else ? Dominic? If not, we can close this as fixed? Rainer
Can still reproduce it, the same way as how Dominic Chambers described it.
In KDE 3.3.0 the table is only relayouted when the windowsize is increased vertically. On decreasing, the table stays unchanged. On increasing, the table stays unchanged until the last table height has been suceeded. From then on, it will be relayouted again.
In 3.4beta1 this is getting even more odd. ;) Yes thats possible. 1. Load the test-case 2. make smaller vertically --> aligns 3. Re-load the test-case 4. make smaller vertically (--> aligns) 5. make bigger vertically --> No align, text stays where it was. 6. Re-load the testcase 7. repeat steps 3-5 8. change size _horizontally_ --> aligned
Still reproduceable with KDE 3.5
Reproducible with KDE 3.5 SVN as of today.
SVN commit 549130 by carewolf: body acts as if it has percentage height in quirks mode (ancient bug) CCMAIL: kling@impul.se BUG: 16017 M +4 -1 render_block.cpp --- branches/KDE/3.5/kdelibs/khtml/rendering/render_block.cpp #549129:549130 @@ -1366,8 +1366,11 @@ // make sure we relayout children if we need it. if (!child->isPositioned() && (relayoutChildren || (child->isReplaced() && (child->style()->width().isPercent() || child->style()->height().isPercent())) || - (child->isRenderBlock() && child->style()->height().isPercent()))) + (child->isRenderBlock() && child->style()->height().isPercent()) || + (child->isBody() && child->style()->htmlHacks()))) + { child->setChildNeedsLayout(true); + } // Handle the four types of special elements first. These include positioned content, floating content, compacts and // run-ins. When we encounter these four types of objects, we don't actually lay them out as normal flow blocks.