The overflow:hidden is only creating a layer if there's any child that overflows the clipping box, but when the animations run in hardware there's no layout code that checks that anymore. See the attached test case.
Created attachment 137170 [details] Simple test case There should be no green outside the red box.
Created attachment 137647 [details] WIP patch, the logic is not bullet-proof enough as-is.
Created attachment 138469 [details] Better fix 2: Keep track of whether we have skipped creating a RenderLayer and create them when needed.
Seems related to bug 81989.
Comment on attachment 138469 [details] Better fix 2: Keep track of whether we have skipped creating a RenderLayer and create them when needed. Removing the review flag on this patch. I will post a patch rolling out r110072 and some of the follow-ups instead as it came under my attention that it caused other regressions.
Created attachment 139286 [details] rollout 110072 take 1.
Created attachment 139460 [details] rollout 110072 take 2.
Attachment 139460 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/fast..." exit_code: 1 LayoutTests/platform/gtk/test_expectations.txt:512: More specific entry on line 325 overrides line 512 fast/workers/storage/use-same-database-in-page-and-workers.html [test/expectations] [5] Total errors found: 1 in 13 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 139460 [details] rollout 110072 take 2. Attachment 139460 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12582344 New failing tests: http/tests/navigation/javascriptlink-frames.html tables/mozilla_expected_failures/bugs/bug2479-5.html
Created attachment 139473 [details] Archive of layout-test-results from ec2-cr-linux-03 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-03 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
CC'ing some bot maintainer so that they see the tide coming as the next roll-out should be good to go.
Created attachment 139554 [details] rollout 110072 take 3. Should be fine now.
Comment on attachment 139554 [details] rollout 110072 take 3. Should be fine now. For the record, I have forgotten to remove hasOverflowClipWithLayer() thus leaving tons of unneeded NULL-checks. I will change that prior to landing.
Committed r115846: <http://trac.webkit.org/changeset/115846>
(In reply to comment #14) > Committed r115846: <http://trac.webkit.org/changeset/115846> Some of the tests this patch unskipped now fail on Mac bots (see <http://build.webkit.org/results/Lion%20Release%20(Tests)/r115846%20(8073)/results.html>). Do these just need new baselines, or are these legitimate failures?
(In reply to comment #15) > (In reply to comment #14) > > Committed r115846: <http://trac.webkit.org/changeset/115846> > > Some of the tests this patch unskipped now fail on Mac bots (see <http://build.webkit.org/results/Lion%20Release%20(Tests)/r115846%20(8073)/results.html>). Do these just need new baselines, or are these legitimate failures? Most of them just need a rebaseline (which I wouldn't have expected as they were not rebaselined since r110072). Only tables/mozilla/bugs/bug4527.html seems to be failing because of some other cause. The change in media/audio-repaint.html seems strange but not unseen (the renderers are removed from the dump instead of being reparented under a RenderLayer). I was going to disable some of the tests to make the bots happy again but I missed the differences as the console didn't show the new failures :(
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > Committed r115846: <http://trac.webkit.org/changeset/115846> > > > > Some of the tests this patch unskipped now fail on Mac bots (see <http://build.webkit.org/results/Lion%20Release%20(Tests)/r115846%20(8073)/results.html>). Do these just need new baselines, or are these legitimate failures? > > Most of them just need a rebaseline (which I wouldn't have expected as they were not rebaselined since r110072). Only tables/mozilla/bugs/bug4527.html seems to be failing because of some other cause. The change in media/audio-repaint.html seems strange but not unseen (the renderers are removed from the dump instead of being reparented under a RenderLayer). > > I was going to disable some of the tests to make the bots happy again but I missed the differences as the console didn't show the new failures :( Ok, I'll update the results (if you're already in the process of doing this, let me know).
I updated the Qt results - http://trac.webkit.org/changeset/115875 Have you got any idea why have we more Qt specific expected results after this change?
(In reply to comment #18) > I updated the Qt results - http://trac.webkit.org/changeset/115875 > Have you got any idea why have we more Qt specific expected results after this change? We haven't rebaselined Chromium yet which may explain for the extra baselines. I don't expect to do the Chromium rebaselining today as I have other stuff on my plate.
Mac results updated in: http://trac.webkit.org/changeset/115879 http://trac.webkit.org/changeset/115885 http://trac.webkit.org/changeset/115890