Head over to the supplied URL to see the re-paint problem first-hand.
*** This bug has been marked as a duplicate of 42032 ***
I do not believe that this bug is a duplicate of bug #42032 but rather an effect of the other bug. I have found another bug (#42356) that is also an effect. I have marked this bug as a dependent of #42032. When #42032 gets fixed, I will see whether this bug fixes itsels or requires further work.
Can someone please confirm this bug so that I can keep track of it on my radar.
setting but to New
Pierre, please triage these from Clayton's list.
I'm going to attach a patch. Marc, Kevin: could you review it?
*** Bug 42032 has been marked as a duplicate of this bug. ***
Pierre, your patch looks fine... Why were we ever calculating a width / height that way before? Width is width regardless of where the origin is, no? I did not apply and run the patch, so I am assuming that it fixes the problem.
Thanks for the help guys :-)
Marc, There is a long history behind that code which you can't suspect considering how small the patch is: changes in CSS2 specs interpretations, attempts to simpler strategies, regressions and finally reinstatement of outdated code. It's finally right now.
Putting on [nsbeta2+] radar. Patch appears low risk. Approved to checkin for patch as shown.
Fix checked in nsContainerFrame.cpp and nsPresShell.cpp
Shashi, Not sure were to check repainting problem specifically. Could you please check in the latest build and let me know ?
Chris: the problem was fairly obvious to see when visiting the page at the URL above. On page load, the text is progressively unveiled by using the clip property, as if you were opening a curtain from the middle of the page towards the left and the right edges of the window. In previous builds, only the left side of the curtain was opening.
These comments are based on the 06-27-09 build (Linux & Win98)... A better page to illustrate this bug can be found at http://www.narain.com/gecko/dhtml/transitions.html This page demonstrates all ten of the pseudo-transitions that can be done using clip. As you can see this demo works perfectly again thanks to Pierre's patch. There is another problem I am seeing but not 100% sure if it is related to this bug. I'll describe the problem and let you guys be the jury. First you will need to head over to http://www.narain.com/gecko/ Once the page finshes loading, you will see six icons fly across your screen. Next the "Gecko's Realm" banner is unveiled. As you can see the banner opens up pretty much as designed. Next you will see a table unveiled using the same technique as the banner, but as you will witness Mozilla struggles to perform this bit of DHTML. Mozilla brings my PIII-450 box to it's knees so I can only imagine what it would look like on a slower system. What I find bizarre is that Mozilla has no problems with the Transitions demo (an image) and the banner (plain text) but runs into trouble with the table.
Shashi: please open a separate bug report for the performance problem and assign to HTML Tables.
Thanks, Pierre. Marking verified fixed in the June 30th builds.